1999 JM8 DATA REDUCTION AND ANALYSIS LOG
========================================

jm8.reduction.log

Lance A. M. Benner

RDF IMAGE CONVERSION
--------------------
A. CBR DATA

1. Determine whether echo is in powers or sigmas

2. Check the tags:
   iyy
   imm
   idd
   rcsta
   ephemeris row and col

3. Convert images in powers->sigmas

4. Set up separate directory trees for CBR and GSB data.

5. If necessary, contact Mike Nolan to modify tags/data and resend.

B. GSB DATA

1. similar to CBR data, but also compare with CBR for consistency.  Compare
   echo strengths for some of the same runs on each day.  

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

1999 October 28

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

Sent out e-mail to Stefano Mottola, Ellen Howell, Michael Hicks, and Dave Tholen
& Rob Whitely to check up on their optical observations of 1999 JM8.  Binzel
previously replied that he would try a night on it but I don't know if he did.

Mottola last mentioned three months ago that he hoped to observe JM8 spectroscopically
from Chile this month.  I dont' know yet whether he actually observed it.

Howell got five nights of spectra at McDonald Observatory in September.  She says 
it's reddish, so the preliminary reduction suggests that the spectra are more consistent
with a C-type than with an S-type.

Hicks previously reported colors suggesting a flat spectrum, possibly a C-type.  
He also speculated that it could be a dormant comet nucleus.  He claims other 
inactive comet nuclei have similar colors.  Hmm...  I don't think we understand
these objects well enough for me to believe they're inactive comets, although it's 
possible.

Tholen has lightcurves but I don't know if he did spectroscopy.  He should combine
his lightcurves with the ones Pravec has assembled from Ondrejov, Hicks, and Krugly.

- - - - - - - - - - - - - - - - - - - - 

1999 JM8 PAPERS
===============
1. Key results from delay-Doppler imaging.  Science or Nature.  Benner et al.

2. Detailed results from radar imaging.  Icarus.  Benner et al. or Hudson et al.
   Include lightcurves with shape modeling.  Perhaps something similar to the
   Castalia and Toutatis papers by Hudson et al. (1997, 1998).  

3. Lightcurves.  Pravec et al.  If we publish the Science/Nature paper first, 
   offer to include the shape model with the lightcurve paper.

4. Spectroscopy.  Howell et al.  Include POS orientation of the shape model to
   to illustrate any rotational variability (a la Eros).  It's not clear how
   Ellen will handle this--whether she plans a paper on JM8 or will include it
   in a multi-target paper.

For the radar papers, I have already outlined a detailed paper.  Steve suggested I
draft that first and then pare it down to a Nature/Science format.  The idea is to 
go into more detail in a subsequent Icarus paper, as has been done with Geographos,
Castalia, and Toutatis.
 
- - - - - - - - - - - - - - - - - - - - 

Ellen Howell and Michael Hicks have independently claimed that JM8 is
most likely a C-type (note that those results are preliminary).  

Pravec obtained H = 15.2, so using Deff = 3.5 km from Scott's preliminary 2nd 
generation shape model, which is based on the first 6 days of Goldstone observations 
only, here's a first-pass at the optical geometric albedo:

reason:/data/ast5/1999JM8/analysis < 16 > pvd
  
Enter the absolute magnitude:
15.2
Enter the diameter (km):
3.5
  
 H =     15.200
 d =      3.500
  
  pv           D (km)
 0.119         3.500

pv = 0.12 is near the high end for C-types.  Clearly this result could change
when an improved 3-D model becomes available using all the radar images.
The optical albedo is actually closer to S-types than to C-types.

- - - - - - - - - - - - - - - - - - - - 

Pravec posted preliminary JM8 lightcurve results on his website at:

http://sunkl.asu.cas.cz/~ppravec/99jm8.htm

Pravec's best-fit period is 6.8 days or 163 hours.  This is comparable to 
the rotation seen in the delay-Doppler images, which between July 24-August 
6 was about 7-8 days.  It should be noted that that estimate is based on
inspection of the images and it doesn't include the effects of sky motion, 
which was substantial.

This "period" could be the rough period about only one of the principal
axes.  Recall from Scott's 2nd model (6 days of Goldstone images) that he
estimates rotation of 3, 19, and -29 deg/day about the principal axes.

The delay-Doppler images after the first 6 obtained at Goldstone seem
to imply more rapid rotation.  

Estimated maximum extents: 3.4, 3.7, and 5.2 km.

Effective diameter ~ 3.5 km

Elongation (max/intermediate axis) = 1.4

- - - - - - - - - - - - - - - - - - - - 

Estimate the damping timescales to principal axis rotation
==========================================================

Harris (1994) gives:

tau ~ (P/C)^3/Deff^2

where P is the sidereal rotation period in hours, Deff is the effective
diameter in kilometers, and C is a constant that depends on the material
properties of the target.

Harris gives C = 17+25-10.

Apply this to JM8, using Deff = 3.5 km

P (d)   P (h)       tau (y)
-----   -----       -------
6.76    162.2         7 E10
12      288           4 E11

The nominal value, 7e10, is comparable to that estimated for Toutatis using
Deff = 2.5 km and P = 130 h.

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

1999 October 28

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

Hicks e-mailed last night to say that he got BVRI photometry, 0.4-0.9 micron
spectroscopy, 0.9-2.5 micron spectroscopy, and 8-12 micron thermal flux 
measurements.  Thus, he may be able to do thermal modeling and provide an
estimate of the effective diameter which we can calibrate using our shape model.
Depending on how the shape inversion and spin vector estimation go, we may be
able to provide POS orientations of the shape that show areas illuminated by
the Sun.  Another obvious goal is to estimate the mineralogic composition of
the surface and to check for heterogeneity.  I don't know when Hicks did his
observations but it's possible that many were at times different from when
Ellen Howell observed.

Of course, there's also the photometry so it is looking as if we stand to 
learn a great deal about 1999 JM8.  My guess is that JM8 will 
become one of the best-studied asteroids (NEAs or MBAs) to date.

- - - - - - - - - - - - - - - - - - - - 

Is 1999 JM8 an inactive comet nucleus?
======================================

Hicks wants to believe that JM8 is an inactive comet nucleus based on its
orbital elements and Tisserand parameter:

reason:/home/lance < 5 > tisserand
  
Enter the semimajor axis (AU):
2.734
Enter the eccentricity:
0.644
Enter the inclination:
13.69
  
  2.734    0.644   13.690
  
q =    0.973
Q =    4.495
  
TISSERAND PARAMETERS
Neptune: T =   11.444
Uranus: T =    7.581
Saturn: T =    4.285
Jupiter: T =    2.981
Mars:    T =    2.549
Earth:   T =    2.824
Venus:   T =    3.155
Mercury: T =    4.092

JM8 has a Tisserand parameter (relative to Jupiter) that suggests a Jupiter-family
comet, but as Valsecchi et al. (1995) showed, both comets and NEAs can evolve into
and out of such orbits so by itself T = 2.98 isn't compelling evidence.  

The orbit does suggest, but not prove, that JM8 is from the outer main-belt and thus
it shouldn't be a surprise if it's an optically (and perhaps radar) dark object.

There are other lines of evidence that could suggest a comet: a coma, a tail, 
association with meteor streams and/or fireballs, and short-term orbital evolution 
dominated by encounters with Jupiter.  

It would probably behoove us to take at least a quick look at the orbital evolution
beyond the close encounters that Jon Giorgini already checked.  As I recall, Jon didn't
find *any* encounters within 1.0 AU of Jupiter over 2000 years centered on the present.
It would still be useful to plot a, e, i, and distance from Earth, Venus, and Mars
and to check for temporary mean-motion and other resonances. 

==> It turns out that Horizons can do this: it can output elements at specific epochs
in tabular format to facilitate plotting.  However, can it output distances from various
solar system objects?  Useful objects include Earth, the Sun, Venus, Mars, and Jupiter.

Using Horizons to compute ephemerides provides the ability to output heliocentric and
geocentric distances.  So how do we compute the distances relative to other objects?
I don't think Horizons has that ability generally available yet.

==> E-mail Jon.

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

1999 November 2

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

Jon replied that one can do this by selecting the viewing site.  Thus, it will be 
necessary to run Horizons multiple times to generate the tables but it's tractable 
and rather quick.

- - - - - - - - - - - - - - - - - - - - 

I've been correspondning by e-mail with Ellen Howell and Michael Hicks.  We've
been comparing preliminary radar results with their preliminary vis-IR-thermal IR
results.  Ellen wrote today that she gets Deff ~7 km and thus pv ~0.02, which 
I don't believe.  I don't know if her Deff is computed from the radiometric 
measurements or whether she's just guessing.  At any rate, 7 km is wrong: it's too
big by a factor of 2 relative to Scott's 2nd pass shape model, which is based on 
the first six days of Goldstone imaging.  I wouldn't be surprised if Deff using
all the data increases somewhat but I doubt it will double.  By "somewhat" I mean
about 0.5-1.0 km.  

If Howell & Hicks' Deff and pv are based on radiometric measurements, which is 
possible because Hicks did some, then this illustrates once again how crude the
thermal modeling really is.  Recall that Scott and Steve found that the Mottola
et al. (1997) thermal modeling of 6489 Golevka is seriously in error and that that
object does not have the high optical albedo that they claimed.  That result is
based on Scott's shape modeling.  Evidently the thermal modeling doesn't work well
in some instances where the asteroid is highly angular, as is the case with Golevka.

Hudson's preliminary model of JM8 suggests that object is roughly wedge-shaped, so
perhaps that, plus the rotation state and the many simplistic assumptions in the
thermal modeling are skewing their results.

- - - - - - - - - - - - - - - - - - - - 

Thoughts about the delay-Doppler images
=======================================

1. The maximum delay extent in many images exceeds 5 km.  I would not be 
surprised if Deff for the shape model increases after we include all the high
resolution images (in Scott's most recent model, only the first 6 days at
Goldstone were included).

2. We mentioned in the press release that there is a large concavity that 
does not appear to be an impact crater.  If not, then what is it?  How else
would an NEA get a large, roughly central concavity that appears crudely 
circular?  
	A. Bifurcation in the shape?  There's no obvious evidence of that for JM8.
	B. Perhaps the feature *is* an impact crater.  This could go back to what
	   Asphaug and Greenberg have studied in recent years: large impacts on 
	   small objects.  

The second possibility is too intriguing to ignore: if that feature is an impact
crater, it would rank among the largest known relative to an object's diameter
and clearly the largest seen on a very small body.  Restate that: if it's a crater,
JM8 would be the smallest body known with such a large crater. This might be worth 
pursuing in a collaboration with Erik Asphaug after we publish the initial paper.  

The bigger picture: if that large feature is an impact crater, then that could be
strong evidence that JM8 is not monolithic (i.e., it's a rubble pile).  In a sense,
JM8 is crudely reminiscent of Mathilde.  We don't have any way to estimate the
density of the whole object, but I will be very curious to see what the bulk 
surface density is from the radar albedo.

Scott's preliminary modeling includes the July 24 image that has the first evidence
for the concavity.  The shape model doesn't show an obvious large depression, though.

There are also at least three craters roughly 1 km in diameter: the two that are 
obvious on the Aug 1 image and a third that is prominent near the top (LE) center
 in the Aug 9 image.  The irregular approaching limb on Aug 5 is another possible
candidate that is reminiscent of depressions that Greenberg et al. (1995, 1996) 
proposed are impacts on Gaspra and Ida and that Asphaug et al. (1996) also suggested
may be impacts on Ida.

3. Grooves on 1999 JM8

In a nutshell, I'm not convinced that I see any, but there are a few lineaments,
especially in the Aug 3 and 4 images when the nearly flat surface was so prominent.  

We might not have enough resolution to see them even if they exist.

4. What is that arcuate feature visible on the receding trailing edge in images
obtained on July 24, August 1, and August 8?  Recall the July 31 image: there's
a pronounced, straight feature on the receding trailing edge.  Perhaps that's what
we're seeing on the other days.  That feature was quite reflective on July 31 so 
perhaps there are some relatively flat surface(s) oriented nearly orthogonal to the
line of sight that were reflecting.  What a complicated object!

- - - - - - - - - - - - - - - - - - - - - 

CW REDUCTION
============

DOY 201 (July 20)
-----------------

We did two runs, four hops, 1000 Hz bandwidth, 4096 point FFT using soln 17

I ran the PSD file through tkrdfreduc without calibrating it.  The goal is to
set and check the tags and check the individual hops for problems.

irun is set correctly.  The colors look OK.  Tsys was set = 16.5 (ch 1), 15.2 (ch 2).
The Tsys values appear to be default values--those are the ones that keep popping
up during every experiment regardless of what the actual values are.  I asked Robert
and Joseph to fix that so we record the actual temperatures but that wasn't available
during the JM8 observations.

The values of Tsys that we measured at the start of the experiment were:
       Tsys
       ----
ch 1   15.93
ch 2   16.78

Unfortunately, if one uses rdftags to change Tsys, the same value get tagged onto
both channels, so it's necessary to split the uncalibrated rdf file using rdfseparate,
open the file with either tkpl and change Tsys, and then joint the files 
using the cat command.  This will probably be necessary for all the cw data.  Fortunately
there isn't very much of it.  

It also turns out that the polarizations got switched.==> set OC to channel 1, not 2.

We transmitted RCP and it was the colder receiver channel.

It's useful to do a calibrated reduction just to check on the polarizations.  Then go 
back and do it again.

So the sense (hot/cold) of the temps needs to be switched.

I changed Tsys appropriately, joined the files, and continued with the calibrated
reduction (blocking into runs).  That produced an error message for both runs
and with both channels:

Using Observatory Gain Constant:  1.11452e+07
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
rnb.Calibrate() error:  rmsc is not what it should be (0.57735) 
                        setting rmsc to 0.280056
(  0)    1.11452e+07  92.74  16.8   686.651    425         4  0.244141    69.632  0.280056  0.00324448
rnb.Calibrate() error:  rmsc is not what it should be (0.408248) 
                        setting rmsc to 0.280056
(  1)    1.11452e+07  92.72  16.8   687.229    425         4  0.244141    69.632  0.280056  0.00324012

Frankly, I don't fully understand this.  ??  Let's forge ahead for now but come
back to this later.

file: 99201.runs.tpl

My terminal (x-jun) just locked while I was moving the mouse...  That was the first time today,
but last week that happened multiple times on several days.  It was really aggravating.

Created and printed file with summed spectra: 99201.sum.tpl

This is the file I was working on when the screen locked.  I can load it with tkgraph
but not with tkpl (it bombs).  ??

There's a *prominent* ~30 sigma central dip in OC and a signficant dip in SC,
but their centers are offset in Doppler.  Strange...  We got about 40 looks so the self
noise is about 16%.  Perhaps that's what we're seeing...  Yeah, that's probably it:
~30sigma/160 sigma = 19%.  (RTT = 94 sec on Jul 20; 4 hops, 20 sec dwells).

The echo is about 2.5 Hz wide.  Need to go back into tkpl to get OCxsec and SC/OC.
Correction: using 3-sigma levels, the OC echo is about 12 Doppler bins wide or 
(11)*(0.244 Hz/bin) = 2.7 Hz.  

Currently: jsnr1 = 509
           jsnr2 = 516

Change jsnr1 = 503
       jsnr2 = 520  This brackets the echoe well

T87 listing
-----------

Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   2-oc  02:34:52  02:35:09  02:36:30   0.0   2.29e-03   2.08e+00  6.2e-03  1.8
Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   2-sc  02:34:52  02:35:09  02:36:30   0.0   2.17e-03   3.61e-01  5.7e-03  1.7 0.173929 0.176737 0.171124

Summary: 
OCxsec = 2.1 km^2
SC/OC  = 0.17 +/-0.003   Call it 0.17+/-0.01 to be safe.  

NOTE: REMEMBER THE RMSC REDUCTION PROBLEM!  

This nominal cross section is double what I got in my preliminary reduction
of the DOY 199/200 data.  

DFREQ   OC SNR
-----   ------
0.244    ~160
1.0       282
1.5       324
1.7       329
1.8       329 <== Bingo
1.9       328
2.0       314
2.5       306
3.0       292

DOY 202 (July 21)
-----------------

We completed one run on DOY 202.  4 hops, 20 sec dwells, RTT = 88 sec, 1000 Hz bandwidth
4 k FFT to give 0.244 Hz resolution with the PSD file.  So we should have about 19-20
looks, or self noise of ~23%.  

Tsys values are set as before:  Ch1 = 15.2, Ch2 = 16.5

Use rdfseparate again and then switch them.  

reason:/data/ast5/1999JM8/proc/cw < 15 > rdfseparate -i 99202.nocal.rdf -o 99202.nocal.sep
Dumping frame 1 to 99202.nocal.sep001.rdf
Dumping frame 2 to 99202.nocal.sep002.rdf

We measured Ch1 = 17.8 and Ch2 = 19.0 on point.

reason:/data/ast5/1999JM8/proc/cw < 16 > cat 99202.nocal.sep001.rdf 99202.nocal.sep002.rdf > 99202.nocal.corrected.rdf

Now run this back through the reduction:

I get the same error as before:
Using Observatory Gain Constant:  1.11452e+07
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
rnb.Calibrate() error:  rmsc is not what it should be (0.57735) 
                        setting rmsc to 0.298142
(  0)    1.11452e+07   83.9  17.8   675.298    425         4  0.244141     61.44  0.298142  0.00249284

We're doing something systematic that rnb.Calibrate doesn't like.  
Need to dig into this...  perhaps ask Keith and/or Mike Thomas.

file: 99202.runs.rdf

Plotted the spectra: this time I got the polarizations right.

Echo is about 10 bins wide or (9)*(0.244) = 2.2 Hz

Echo is very strong.  

dfreq    OC SNR
-----    ------
0.24      282
1         366
1.3       383
1.4       383 <== 
1.5       381
1.6       376
1.7       374
2         343

T87 listing
-----------

Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99202.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-oc  17:41:21  17:41:01  17:42:54   0.0   2.66e-03   2.44e+00  6.0e-03  1.2
Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99202.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-sc  17:41:21  17:41:01  17:42:54   0.0   2.49e-03   4.16e-01  6.2e-03  1.5 0.170393 0.172946 0.167843

OC xsec = 0.24 km^2
SC/OC   = 0.17+/-0.003  adopt 0.17+/-0.01 again.

Cross section and ratio are consistent with results from the previous day.

An idea: repeat the reduction using the version of tkrdfreduc on intruder.  See if there
is any difference in with the error message.

DOY 204 (July 23)
-----------------

In this case the system temps look OK.  Evidently Carl entered the actual values.

2 hops, 4 k FFT, 1000 Hz bandwidth

irun is fine.  That problem has been solved.

I did the calibrated reduction: no rmsc error messages this time.  ??
However, something weird did happen with the reduction: there's a strong (> 1000 sigma) spike 
at the extreme negative frequency.  We've seen this before but I don't know the cause.
The question is whether or not it will corrupt the cross section.

change jsnr1 = 1020, jsnr2 = 1035.  

bandwidth: 9*(0.244) = 2.2 Hz

dfreq   OC SNR
-----   ------
0.244    321
1.0      423
1.4      439 <==
1.5      439
1.6      436
1.7      434

Target 1999JM8             from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-oc  00:36:44  00:37:14  00:37:59   0.0   1.85e-03   2.03e+00  4.4e-03  1.4
Target 1999JM8             from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-sc  00:36:44  00:37:14  00:37:59   0.0   2.01e-03   4.14e-01  4.8e-03  1.4 0.203447 0.205839 0.201056

OCxsec = 2.0 km^2
SC/OC = 0.20+/-0.01 (adopting generous errors again)

This ratio is statistically larger in a significant way relative to 
the results from the previous two days.  Something systematic?  It might
have been the result of lower system temperatures.  Or perhaps that
side of the asteroid is a bit rougher.  

DOY 205 (July 24)
-----------------

We did two runs with a 4 k FFT 1000 Hz sampling, 2 hops, using solution 21.

Tsys for ch 1 is set incorrectly to 7.1 K--it should be 17.1 K.
Tsys for ch 2 is fine (17.9 K).

reason:/data/ast5/1999JM8/proc/cw < 23 > rdfseparate -i 99205.nocal.rdf -o 99205.nocal.sep
Dumping frame 1 to 99205.nocal.sep001.rdf
Dumping frame 2 to 99205.nocal.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 24 > cat 99205.nocal.sep001.rdf 99205.nocal.sep002.rdf > 99205.nocal.corrected.rdf

Calibrated reduction seemed to go fine: no error messages.  However, the
e/m values are *very* low...  near 0.02...  Let's look at the individual hops.
...Actually, just from looking at the two calibrated runs it's obvious that the
first one is bad.  

There are six hops total: the first three look bad (first run).  

I deleted the three bad hops.  file = 99205.nocal.corrected2.rdf.  Run it through again...
e/m is better, especially for SC.  OC still has some low values.  
file = 99205.runs2.rdf

plot: 99205.sum.tpl

dfreq    OC SNR
-----    ------
0.244     397
1.0       634
1.3       643
1.4       646
1.5       646 <==
1.6       643
2.0       623

13(0.244 Hz/bin) = 3.2 Hz

change jsnr1,2 from 1021,1028->1019,1034  file: 99205.runs2.rdf
Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99205.runs2.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   2-oc  17:00:38  17:01:08  17:01:53   0.0   1.50e-03   2.51e+00  3.8e-03  1.6
Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99205.runs2.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   2-sc  17:00:38  17:01:08  17:01:53   0.0   1.57e-03   5.51e-01  3.6e-03  1.3 0.21987 0.221363 0.218378

OCxsec = 2.5 km^2
SC/OC = 0.22+/-0.01 (again adopting much larger standard errors--almost 10 times larger)

The ratio is 0.05 higher on July 24 than it was on July 20 & 21--a difference 
that is statistically significant.  Perhaps we're seeing evidence of heterogeneity.
Alternatively, we could be seeing systematic effects.  

DOY 208 (July 27)
-----------------

[See additional notes with the July 28 reduction concerning the July 27 results]

I fired away with a quick calibrated reduction to see what would happen. 
SC e/m is fine; OC e/m has some that are low.  I don't understand this.

Go back to an uncalibrated file to check the hops and tags.

There are two runs, two hops, 0.244 Hz/bin (1000 Hz sampling & 4 k FFT)

Tsys: ch1 = 15.4, ch2 = 16.5.  

tkpl just bombed again when I tried to load an existing template.  
create isn't printing.  Did the daemon die?  --> Deal with it tomorrow;
for now, print to lexmark.

Tsys should be 18.2, 19.5.

reason:/data/ast5/1999JM8/proc/cw < 26 > rdfseparate -i 99208.nocal.rdf -o 99208.nocal.sep
Dumping frame 1 to 99208.nocal.sep001.rdf
Dumping frame 2 to 99208.nocal.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 27 > cat 99208.nocal.sep001.rdf 99208.nocal.sep002.rdf > 99208.nocal.corrected.rdf

e/m is similar to the previous day's file: SC values are close to unity;
OC values vary between 0.15-1.0

No error messages.

It is amazing to see such strong echo power in each OC hop.  Wow.

May be seeing the sinx/x signature in the echo:

rows  1015  1016  1017  1018  1019  1020  1021  1022  1023  1024  1025  1026  1027  1028  1029  1030  1031  1032  1033  1034  1035
----------------------------------------------------------------------------------------------------------------------------------
   1 -0.75 -0.61  2.93  1.00  2.39 12.14  4.57 26.21 95.96161.36427.13167.63188.85286.01118.90129.95 76.53 67.24  2.04  4.75  0.58

rows  1015  1016  1017  1018  1019  1020  1021  1022  1023  1024  1025  1026  1027  1028  1029  1030  1031  1032  1033  1034  1035
----------------------------------------------------------------------------------------------------------------------------------
   1  1.51  0.74 -1.10  1.10  0.30  0.04  2.36  1.55 24.14 20.83 23.27 66.46 47.33 28.88 30.45 23.51 16.92  3.71  1.85  6.41 -1.20

Top row is OC; bottom is SC.

So we see echo power in about 14 bins*0.244 Hz/bin = 3.4 Hz

dfreq   OC SNR
-----   ------
0.244    427
1.0      505
1.5      567
1.8      571
2.0      576
2.2      579
2.3      579 <==
2.5      567

rows   jsnr1   jsnr2
--------------------
   1  1021.0  1028.0

      1018    1035     <== change to these values.

Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   2-oc  01:33:01  01:33:20  01:34:20   0.0   7.45e-04   1.32e+00  2.1e-03  1.9
Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   2-sc  01:33:01  01:33:20  01:34:20   0.0   7.98e-04   2.38e-01  2.3e-03  2.0 0.180003 0.181752 0.178256

Wow!  OC xsec dropped by nearly a factor of two!
The ratio also dropped back to close to its previous value.

OC xsec = 1.3 km^2
SC/OC   = 0.18+/-0.01

The OCxsec and ratio are consistent with results obtained on July 20, 
when the images show that a "pointed" end was at the LE.  That is,
the orientation of JM8 on those two days may have been similar (it's 
hard to tell from the images because of the SNR and resolution).

One obvious question: will the OC xsec and SC/OC be similar on Aug 1 
to their values on July 24?  Those are two days when the images
looked very similar.  In retrospect, I should have done some 
CW observing on August 8, when the orientation was similar
to those on July 24 and August 1.  We certainly had enough time.
I should have analyzed the CW data during the tracks.  

The lower OCxsec on this day could also be the result of the asteroid's
orientation.  The images show the pointed end toward the radar, so 
due to the shape, it might have been naturally "dimmer" similar to 
what we saw with Geographos and Bacchus at certain phases.  That is
consistent with the images which were weaker than I expected.

Skip ahead a couple of days in light of the results above...

DOY 213 (August 1)
------------------

We did two CW runs, 2 hops, 1000 Hz sampling, probably 4 k FFT.
(That's what I would have instructed.  I was at Arecibo that
day and Steve was on the east coast.)

rows    tsys
------------
   1    15.1
   2    15.1
   3    15.1
   4    15.1
   5    15.1
   6    15.1

rows    tsys
------------
   1    16.1
   2    16.1
   3    16.1
   4    16.1
   5    16.1
   6    16.1

Randy's log indicates that the temps should be ch1, ch2 = 17.7, 18.6

reason:/data/ast5/1999JM8/proc/cw < 30 > rdfseparate -i 99213.nocal.rdf -o 99213.nocal.sep
Dumping frame 1 to 99213.nocal.sep001.rdf
Dumping frame 2 to 99213.nocal.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 31 > cat 99213.nocal.sep001.rdf 99213.nocal.sep002.rdf > 99213.nocal.corrected.rdf

Individual hops look great.  

e/m shows same pattern as before: SC is pretty good (close to unity); OC is
highly variable between about 0.1 - 1.0
3
file: 99213.runs.rdf

Second calibrated spectrum looks odd: did something go wrong?  It could just
be chi-square noise.

change jsnr1, jsnr2 = 1010,1040.  That's plenty wide.

dfreq   OC SNR
-----   ------
0.244    437
1.0      651
2.0      841 
2.5      874
3.0      883
3.1      884 <==
3.2      883
3.5      875

21 bins(0.244 Hz/bin) = 5.1 Hz

Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99213.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/08/01   2-oc  12:05:13  12:05:14  12:06:14   0.0   6.68e-04   2.12e+00  2.3e-03  2.9
Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99213.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/08/01   2-sc  12:05:13  12:05:14  12:06:14   0.0   6.98e-04   6.41e-01  2.3e-03  2.7 0.302561 0.303706 0.301416

OC xsec = 2.1 km^2 <== recall that I got 2.5 km^2 on July 24.  My guess is that we're 
seeing some real OC xsec variations superimposed on systematic effects that could
easily be 25-35% (as we saw with 1991 CS).

SC/OC = 0.30!  Whoa... this is probably systematic.  That's a *huge* excursion
from previous values.

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

1999 November 4

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

Back after spending some time working on Mercury CW data...it looks like the 
subreflector's z-axis is off.  

DOY 209 (July 28)
-----------------

We used the same setup as on other days: 0.244 Hz res'n, 4 k FFT, 1000 Hz sampling.

We got part of 3 hops.  Tsys ch1 = 15.6, ch2 = 16.7 but should be 15.9, 17.1.

Not much of a difference but let's correct anyway.

reason:/data/ast5/1999JM8/proc/cw < 20 > rdfseparate -i 99209.nocal.rdf -o 99209.nocal.sep
Dumping frame 1 to 99209.nocal.sep001.rdf
Dumping frame 2 to 99209.nocal.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 21 > cat 99209.nocal.sep001.rdf 99209.nocal.sep002.rdf > 99209.nocal.corrected.rdf

Something went wrong with the reduction:I got sdev = infinity.  

Echo is very strong.  

Let's check the hops: OC looks OK...  check tags: somehow the transmitter power 
was set = 0.  That's the problem.  Easy enough to fix...  We had Ptx = 445 kW.

That worked.

This data has a very low SC/OC ratio.  Something wrong with the system?

T87 listing:

Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-oc  17:14:17  17:14:14  17:15:14   0.0   7.44e-04   4.37e+00  1.8e-03  1.4
Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-sc  17:14:17  17:14:14  17:15:14   0.0   8.01e-04   5.60e-01  2.6e-03  2.5 0.128067 0.128656 0.127478

This gave an unbelievably large OC xsec = 4.4 km^2.  Note that the ratio is way down
relative to the other days.  These could be real effects on the surface, but a better
guess is that there were systematic problems.  

One thing that has become apparent is that I should have done more CW observations--
say, even 10 runs per day on the longer tracks would have been useful.  

I'm checking tags used in the calibration.  What about igw, the integer gate width?

rows     igw
------------
   116777217024.0

According to Keith's description, this is supposed to be in microseconds.  If so,
then it's huge: 1.2 E5 usec, which is more than one day.  Is that right?  The problem
is that I don't know what the igw really is.  I sent e-mail to Steve to ask.

The Arecibo system has a parameter rigw which is the sampling rate in usec.
So are they related?  Unfortunately, I've never paid much attention to igw before.

At any rate, the echo occupies 13 Doppler bins at echo powers exceeding 10 sigma,
so B = 12(0.244 Hz/bin) = 2.9 Hz

dfreq  OC SNR
-----  ------
0.244   2005  <== There's a LARGE spike that is much higher than the other elements.
0.4     2567  Yow!
0.5	2071
0.6     2016
1.0     1852
1.5	1827
1.8     1892
2.0     1917  Now we're smoothing the whole spectrum, not just the spike
2.2     1924
2.3     1922
2.5     1911

The spectrum has resolution of 0.244 seconds and there are about 37 seconds
of data in it.  That's only 9 looks, so self noise is outrageous: ~33%.  
Nevertheless, the spike is much more than 1/3 larger than other spectral
elements (it's more than 1000 sigma), so perhaps we were getting a glint.
Compare with the image: Yes, this is plausible--there are two spikes in the
spectrum, one slightly on either side of 0 Hz.  The really strong one is on
the negative side.  There are two bright concentrations of pixels and their
locations match those in the CW spectrum.  So I think we got a couple of regions
with a lot of surface area oriented close to normal to the line of sight 
and thus got whopping echoes.  Neat!

It also turns out that increasing the frequency resolution dropped the SNR 
of the spike, so it's clearly a narrow-band feature.  Smoothing the frequency
resolution to 0.5 Hz increased the SNR somewhat, so the width of the feature
exceeds 0.24 Hz.  Checking the image...the feature appears to be close to 0.5
Hz wide.  Well, well, well. Note that 0.4 Hz maximizes the S/N.

This is reminiscent of the spikes Dave Mitchell described in his 5-target
MBA paper.  This suggests that I take a closer look at the other CW data.
I now wish I had obtained CW data on the few days at Goldstone when we
didn't get any, especially the last two.  (We could, of course, always
create CW spectra from the images.)  

Actually, I just discovered that I was comparing the CW spectrum to images from
the wrong day (Jul 27, not Jul 28).  The July 28 image is the correct one.  It's
the image with the "twin peaks" and it's one of the four in the JPL press 
release.  

As a note, the July 27 CW spectrum *does* show two spikes that 
match the distribution of echo power on the LE in the images.  The spikes are
~100-250 sigma stronger than adjacent Doppler bins.  This raises an interesting
question: some of the spikes could lead one to believe that there are central
dips, when in fact what we see in the images is relatively small
areas with concentrated narrow spikes of echo power.  So one has to be careful about 
misinterpreting central dips as deficits--they might really 
indicate regions with surface area orthogonal to the line of sight.  
For July 28, there are two CW spikes and there *is* a central dip on the LE 
because there are two "peaks," but the spikes are so narrow that 

What would we have seen in the 1991 CS images?  There were hints of glints 
in the cw data but they didn't repeat on subsequent rotations so I intentionally
underinterpreted them.  

DOY 212 (July 31)
-----------------

We did two runs with 0.244 Hz resolution.  

This time Ptx is set, but the gain is down by ~10%.  ??
I wasn't at Goldstone to record the system temps on point, but by this time
Joseph and had them back on the log file.  The values tagged on the data
are 1,2 = 15.3, 16.4.  The log file gives

Run  ch1  ch2
---  ---  ---
1   15.3  16.2
2   15.1  16.2

==> Close enough.  Don't change them.

e/m values show the same pattern seen before.  SC is better than on other days
but still not as close to 1 as I'd like.  

We got two runs with about 80 sec of integration. That's about 19 looks,
so self noise is ~ 1/sqrt(19) = 23%.  

There are two prominent spikes in the cw spectrum.  The spectrum, minus the
spikes, is asymmetric, which agrees with the delay-Doppler image.  The image
shows no evidence of bifurcation.  Without going into the image data it's
not completely obvious where the really strong peak is coming from--it's obviously
on the LE.  There may be a rather small, almost flat area just positive of 0 Hz
that could be the source...by flat I mean there are five adjacent pixels with 
the same range.  The resolution was 0.05 Hz, so with 0.244 Hz resolution the
cw spectrum should have just about match-filtered this if that's truly the
source of the feature.  Let's change the filtering to check...

The feature gets stronger upon smoothing to 0.4 Hz.  Hmm... Maybe this is coming
from a somewhat larger area.  

There's also a 15-sigma spike at about -4 Hz, which is about 1.5 Hz from the edge
of the echo.  What is it?  I don't recall seeing this in other spectra nor do I
see an obviou signature in the image...actually, the image doesn't go over far
enough in Doppler to see it.  Check the full delay-Doppler array...nothing.  
What I'm thinking about are possible satellites.  Need to pay more attention to
the other CW data--if there's a really small companion only one or two Doppler bins
wide then it might easily get lost in the noise in the images due to the SNR 
penalty we suffer.  Once again this highlights the need to look at as much of
the data as possible while taking it and right afterward.  

Another thing I noticed is that the background removal isn't ideal--need to increase
the estimated bandwidth.  The baseline is coming in a bit negative.  I checked 
the whole spectrum--not just the zoomed in view near the echo--and found that
there are a number of ~10 sigma spikes, so we're still in the chisquare noise
realm.  The baseline *is* a couple of sigma negative.  The echo is so strong
that that's not enough to affect the OC xsec or SC/OC ratio.

Perhaps the chi-square noise is affecting the estimated/measured rms during the
reduction?  One way to test that would be to compare with the CW data obtained
during the first track (DOY 199-200) when we got quite a bit of CW data.  

dfreq    SNR
-----   ------
0.244    831
0.4     1063
1.0 	 903 
2.0 	1209
2.5	1276
2.8	1294
3.0	1295
3.2	1292
3.5	1278

change jsnr1,2 = 1014,1034.  That will include the sinc^2 component, but that's OK
since it's dwarfed by the echo.  

Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99212.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/31   2-oc  17:02:54  17:03:03  17:04:03   0.0   5.66e-04   2.58e+00  1.8e-03  2.6
Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99212.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/31   2-sc  17:02:54  17:03:03  17:04:03   0.0   6.06e-04   5.16e-01  2.1e-03  2.8 0.199825 0.200639 0.199011

There are about 17 Doppler bins with SNR > 10 sigma, so 
(17)*(0.244 Hz/bin) = 4.1 Hz.

Glints
------
There are weaker glints in cw spectra from other days.  Notably on July
21 and 23--and those glints match well with bright spots on the LE in 
the images.  

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

1999 November 8

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

I spoke with Keith over the weekend about igw.  He said he could dig through some notes
about what values I should be getting and he reiterated that it's used in the calibration.
His recollection is that typical values are about 125.  When I told him the values
I'd been getting he said they're clearly wrong.  He also suggested I check old calibrated
data to see what values we've gotten.  

My recollection is that I haven't been paying all that much attention to igw until 
recently.  I seem to remember seeing large values in the past but I'll have to check to be
sure.

- - - - - - - - - - - - - - - - - - - - 

Continue with the CW reduction... return to the first track, paying particular
attention to igw.  I'm going to do some experiment to check the effects of
igw on the cross sections.

DOY 199-200
-----------

We have four PSD files from this track:
      file                bandwidth  FFT  dfreq  runs  hops dwell
PSD99199-16k.1999JM8        4000     16k  0.244   8
PSD99199-4k.1999JM8         4000      4k  0.978  
PSD99199-8k.1999JM8          500      8k  0.061  11     2    30
PSD99199B-8k.1999JM8        1000      8k  0.122   3     4    20

8 runs total in the first two files.  

Let's start with the last file: PSD99199B-8k.1999JM8

Tsys tag values:
ch1 = 15.2
ch2 = 16.5
These are obviously "default" values.
According to the electronic log, Tsys was ~20, 21 K for ch1, ch2 
during these three runs.  I did not note Tsys in my electronic log.
It was right about this time when Joseph modified the AC software to
record both temperatures.  

Let's use the average of the temps for the three runs.  
reason:/data/ast5/1999JM8/proc/cw < 18 > rdfseparate -i 99199B.nocal.rdf -o 99199B.nocal.sep
Dumping frame 1 to 99199B.nocal.sep001.rdf
Dumping frame 2 to 99199B.nocal.sep002.rdf

Average system temps: Ch1 = 20.35, ch2 = 21.23

Run through the calibration...Got some errors:
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
rnb.Calibrate() error:  rmsc is not what it should be (1) 
                        setting rmsc to 0.436436
(  0)    1.11452e+07  97.33  21.23   653.429    425         4   0.12207    57.344  0.436436  0.00407415
rnb.Calibrate() error:  rmsc is not what it should be (0.707107) 
                        setting rmsc to 0.436436
(  1)    1.11452e+07  97.32  21.23   652.444    425         4   0.12207    57.344  0.436436  0.00407813
rnb.Calibrate() error:  rmsc is not what it should be (1) 
                        setting rmsc to 0.471405
(  2)    1.11452e+07  97.31  21.23   651.022    425         4   0.12207    49.152  0.471405  0.00441215

Again, I don't understand this.  The e/m rms is closer to unity on this data than with
any of the other JM8 cw data that I've looked at.  Nor do I understand why rmsc is 
being set to the values above.  --> Need to e-mail Keith.  Arg... 

Is this related to chi-square noise?  There's certainly plenty of that in each 
spectrum.  One way to check would be to repeat the reduction with a much shorter
FFT, or compare with other recent data that has lots of looks.  

Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99199b.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   3-oc  07:12:32  07:12:06  07:14:06   0.0   2.31e-03   1.38e+00  7.6e-03  1.3
Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99199b.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   3-sc  07:12:32  07:12:06  07:14:06   0.0   2.41e-03   2.03e-01  7.7e-03  1.3 0.147198 0.152886 0.141519

So I get OC xsec = 1.4 km^2, SC/OC = 0.15+/-0.01 (again adopting generous errors).

This is one of the smallest cross sections we have observed for JM8; only July 27 was lower
or comparable.  

dfreq    OC SNR
-----    ------
0.122      85
1.0       169
1.2       175
1.3       176
1.4       176
1.5       175

Here's the echo power at the raw 0.122 Hz resolution:

rows  1030  1031  1032  1033  1034  1035  1036  1037  1038  1039  1040  1041  1042  1043  1044  1045  1046  1047  1048
----------------------------------------------------------------------------------------------------------------------
   1     2    -0    -0    23    38    62    85    55    64    58    51    50    47    35    16     7     1     1    -0

rows  1030  1031  1032  1033  1034  1035  1036  1037  1038  1039  1040  1041  1042  1043  1044  1045  1046  1047  1048
----------------------------------------------------------------------------------------------------------------------
   1    -0    -1    -1     2     5     7     8    10     9     9    12     6     6     6     2     1     1    -0     1

The echo is 13 bins wide or (12)*(0.122 Hz/bin) = 1.5 Hz, using echo power
above the 7-sigma level.

Hey--I just had a realization: need to set jsnr1 and 2 correctly with really
strong echoes or else the normalization and radar cross section could get
messed up because the background removal would be wrong.  So if one did a 
calibrated reduction as I did and found that jsnr1 and 2 were wrong, then
you could go back into the uncalibrated file, set them correctly, and then
proceed.

I found a bug: I changed tsys but rdftags didn't recognize the change.  The header
information didn't update. 

Integer Gate Width: DOY 200
---------------------------  

Here's what I get for igw: 
rows     igw
------------
   1 67108868096.0
   2 67108868096.0
   3 67108868096.0
   4 67108868096.0
   5 67108868096.0
   6 67108868096.0
   7 67108868096.0
   8 67108868096.0
   9 67108868096.0
  10 67108868096.0
  11 67108868096.0
  12 67108868096.0
  13 67108868096.0
  14 67108868096.0
  15 67108868096.0

Each row refers to a hop.

Steve doesn't know if igw is used at Goldstone or not, but at Arecibo
it's the sampling rate.  Is igw being used with Goldstone data, as Keith
believes, or not? 

Let's e-mail Robert Frye to ask how this is being set.==> He didn't know what
igw was.  It doesn't look like it's being set by the VME.  Next step: check
the reduction source code.  Ugh.  

I repeated the das->rdf conversion.  That uses "das2rdf" which sets the tags.
Now to find the source code...
I haven't found "das2rdf" yet, but I did find: 
reason:/dev1/rosema/release/src/das/DasFile.cc
In it is the following:

  tags[IGW]     =   1.0e6 * (das->points()/tags[DFREQ]);

This seems to define igw = (1e6)*(npoints/dfreq).  So, for the current file,
this would give (1.0e6)*(8192)/(0.12207) = 6.71E10.  <== That matches the
values I got above.  But why?  What does it mean?  How is it used?  So the 
values of igw are being set according to their definition.  It may turn out 
that this isn't important, but I'd like to understand what's going on.

I found das2rdf.cc in the same directory as DasFile.cc, but there was no 
obvious information about igw.  Perhaps the more important question is how
is this used?  Need to locate where, later in the pipeline, that igw is used.

I didn't see any usage of igw in doscreen.cc, blocking.cc, or in rnb.cc.

Here's something useful that I found in rnb.cc:

/* ------------------------------------------------------------
		   C a l i b r a t e

    Calibration involves setting the SDEV tag correctly for 
    each spectrum.

    SDEV is the kilometer square equivalent of one standard
    deviation of the noise power, and is calculated as:

                                   ( (rtt^4) * tsys  )
    SDEV = GainConst(observatory) *( ----------------) * dfreq * rmsc
                                   ( txgain*rcgain*pt) 

    Where:

      GainConst(observatory) is a gain constant dependent on 
                             wavelength, the area of the telescope,
                             unit conversions, etc.  
			     The correct values for these 
			     constants are defined in 
			     goldstone.h and arecibo.h

      rtt    is the round trip light time in seconds to the target, 
             assigned to the data by the tagging program that reads 
	     the value from the ephemeris.

      tsys   is the system temperature in degrees kelvin.  This
             is assigned by the tagging program either by reading 
             a system log file, or by estimating the temperature
             from a function of antenna pointing.

      txgain The one way system gain of the transmitter
      rcgain The one way system gain of the receiver
             These two values are calculated by the tagging
             program as a function of antenna pointing and 
             transmit and receive locations.  The two values are
             multiplied together, divided by 10^12, and put in the
             GAIN tag.

      pt     is the system transmit power, in kilowatts.  This value
             is assigned by the tagging program from a system log. 

      dfreq  is the frequency resolution of the fft, and is assigned
             by the tagging program as a function of setup parameters.

      rmsc   Is the calculated rms noise in the reduced signal 
             spectrum before normalization.

             rmsc is calculated differently depending on what 
	     sort of background removal was done.  

             In early reduction, rmsc was calculated from the
             number of hops averaged and the total noise power in the
             baseline.

                    (   n         1      ) ^ 1/2
             rmsc = (  --- * ----------- ) 
                    (  n-1   tau * dfreq )

	     Where n is the number of hops averaged.  If polynomial
             background removal is used, (1 hop), then (n/(n-1)) is 
             replaced with 1.

             tau is the total accumulated integration time, which is 
             the sum of the taus of the individual input spectra.

             dfreq is as described above.

--------------------------------------------------------------- */

I don't see any use of igw whatsoever.  Is it obsolete?  I did a search
on the string "igw" but found nothing.  Keith also includes an extensive
discussion of background removal but that doesn't involve igw either.  

Move on to another DOY 199/200 file

99199-8k
--------

This file has 0.061 Hz resolution: sampling = 500 Hz, FFT = 8192.  I was
going for resolution because the bandwidth was narrow.  We did 11 runs to
improve the chi-sq noise statistics.  There were 10 good runs (first was
bad and is not included in the PSD file).  

Unfortunately I didn't record Tsys, but the electronic log got it for OC:
16.5 K, which is also the value in the file.  Tsys was stable about that
value for all 10 runs.  We don't have the SC tsys so use the default value
of 15.2, which should be close enough. 

Gain = 0 for runs 1 and 4.  Defaulted to 1.0.  Somehow the colors didn't 
get set correctly--they're the same on both hops for those two runs.
==> Delete those runs in the uncalibrated file.  
==> That worked, leaving 8 good runs.  

!! Something is wrong: the spectrum is rubbish !!

There are lots of several thousand sigma spikes.  All the runs are bad.
That's odd because the VME real-time display looked fine.  

I tried reducing these data on July 30 and encountered the same problem.
It may be necessary to go back to the voltages and pick a different FFT,
(different file--perhaps that file is OK).  I don't understand what happened.

The only hint of trouble during the reduction (other than the problem I
found and corrected above) are the large number of outliers.  Maybe Keith's
cw software has trouble with extreme chisquare noise?  Recall that we got only
one look/hop.  

I checked each hop--see the same problem.  Maybe this is something wrong with 
the way the VME writes the data?  It would be worth doing a quick test the next 
time we get a really strong target.  I'm going to go on to the first file--the
one where we changed the FFT on the fly--and then I'll come back to this one
by working with the voltages.  

99199-4k
--------
I started the JM8 experiment with 4000 Hz sampling and a 4 k FFT.  We 
switched the FFT on the fly during tx between the first and second runs.
Evidently we created a new file with the 16 k data to avoid the reduction
problems that I had with the 1999 GU3 data two months earlier.  

We used 4 hops with 20 second dwells, but we actually got parts of
two more hops for a total of 6.  I did a quick calibrated reduction--the rmsc
error appeared again.  The system temps are set incorrectly again:
ch1,2 = 15.2, 16.5.  They should be 16.0, 17.8.

reason:/data/ast5/1999JM8/proc/cw < 10 > rdfseparate -i 99199-4k.nocal.rdf -o 99199-4k.nocal.sep
Dumping frame 1 to 99199-4k.nocal.sep001.rdf
Dumping frame 2 to 99199-4k.nocal.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 11 > cat 99199-4k.nocal.sep001.rdf 99199-4k.nocal.sep002.rdf > 99199-4k.nocal.corrected.rdf

Here's the echo power:

rows 510 511 512 513 514 515 516 517 518 519 520
------------------------------------------------
   1   0   1   2   6  52 156  11   2   2   1   1

rows 510 511 512 513 514 515 516 517 518 519 520
------------------------------------------------
   1   0  -0   0   2   5  23   1   0   0   0  -1

change jsnr1,2->510,517.  Most of the echo is in two cells.  Recall that
dfreq = 0.98 Hz, so we didn't really resolve it in Doppler.  Was the echo smearing
in Doppler?  It shouldn't have been--we had a really good ephemeris (15) based
on a 9 year optical arc.  

Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99199-4k.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   1-oc  21:14:19  21:14:09  21:16:09   0.0   7.16e-03   1.64e+00  1.0e-02  1.9
Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99199-4k.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   1-sc  21:14:19  21:14:09  21:16:09   0.0   7.97e-03   2.43e-01  1.0e-02  1.6 0.147665 0.154021 0.141321

OCxsec = 1.6 km^2, SC/OC = 0.15+/-0.01.  These results are consistent with those obtained
using file 99199b.  Perhaps on this day the asteroid was in an "end-on" orientation
relative to the line of sight.

dfreq  OC SNR
-----  ------
0.98    156
1.4     186
1.5     193
1.6     199
1.7     162  This change is a bit weird...
2.0     161

99199-16k
---------
We got 6 runs with this setup.  

We recorded OC tsys but not SC (Joseph fixed that later on the same
night).  Use the earlier on-point values from above:
ch1,2 = 16.0,17.8 K.

reason:/data/ast5/1999JM8/proc/cw < 23 > rdfseparate -i 99199-16k.nocal.rdf -o 99199-16k.nocal.sep
Dumping frame 1 to 99199-16k.nocal.sep001.rdf
Dumping frame 2 to 99199-16k.nocal.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 24 > cat 99199-16k.nocal.sep001.rdf 99199-16k.nocal.sep002.rdf > 99199-16k.nocal.corrected.rdf

I've been a bit thick: I keep using Deff = 3.5 km, P = 8 days.
But the echo is wider on some days--should use Deff = 5 km.

Individual hops look OK: clearly see the echo in each.  Minor amounts of
noise near the left edge in several hops.  

Got a bunch of rnb calibrate errors again due to rmsc not matching rmsm.

?? e/m per was close to unity for each hop. 

Throughout the reduction I have saved the rdfreduc ouput log files.  

I changed jsnr1,2 -> 2050,2063.  There's some sincx^2 in there, but it
shouldn't have much of an effect.

Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99199-16k.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   8-oc  21:37:56  21:38:16  21:39:30   0.0   1.63e-03   1.73e+00  3.8e-03  1.3
Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99199-16k.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   8-sc  21:37:56  21:38:16  21:39:30   0.0   1.82e-03   3.56e-01  4.0e-03  1.2 0.205754 0.208141 0.203369

The ratio is quite a bit higher than with the other data on this date.  SCxsec
went up. 

dfreq  OC SNR
-----  ------
0.244   252
1.0     441
1.2     453
1.3     453
1.4     451
1.5     446

Here's the echo from a weighted sum of all six runs:

rows20502051205220532054205520562057205820592060206120622063
------------------------------------------------------------
   1   3   3   7  22 179 252 229 222 103  25   7   3   3  -0

rows20502051205220532054205520562057205820592060206120622063
------------------------------------------------------------
   1  -1   2  -0   2  27  46  47  46  22   3   0   1   1   1

There are 9 bins with echo power exceeding 7 sigma, so 
(8)*(0.244 Hz/bin) = 2.0 Hz

That's wrong: we're seeing (sinx)^2 again, so ignore the two 7-sigma
points.  That drops the bandwidth to 1.5 Hz.  

Rats... I accidentally overwrote the *runs.rdf file when I computed
the weighted sum.  Well, no big deal--I wasn't going to use the
individual runs anyway.  Can always repeat their reduction later
if needed.  

The OCxsec results show a 20% variation over an interval of about
10 hours.  JM8 rotates so slowly that there shouldn't have been that
much REAL variation, so we're seeing systematic effects of about 20%
(OCxsec between 1.4-1.7 km^2).

>> Deal with the 0.061 Hz data tomorrow <<

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

1999 November 9 & 10

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

Return to file 99199-8k
-----------------------

There is something wrong with the PSD file, so let's work with the 
voltages.  Here's a synopsis of how to use dofft:

reason:/data/ast5/1999JM8/proc/cw < 4 > dofft -h

Usage: dofft [-Flrs] [-d diam] [-p period] -f lfft -i ifile 
                -o ofile -x prdxfile 

-F             Flip i's and q's in voltage file
-l             Log ast_spec output to a file called ast_spec.log
-r             Fix the hop colors
-s             Sum all looks in each hop
-d diam        Diameter, in km
-f lfft        FFT length
-i ifile       Input file
-o ofile       Output file
-p period      Period, in hours
-x prdxfile    PRDX file

Recall that this file had two hops and 500 Hz sampling.

Try 1024-point FFT:

reason:/data/ast5/1999JM8/proc/cw < 15 > dofft -d 3.5 -f 1024 -i VOLT99199-8k.1999JM8 -o 99199-8k.nocal.1024.rdf -p 192 -x PRDX.OUT.s15
contents of ast_spec control file:
1024,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199-8k.1999JM8
RDFOUT_1=99199-8k.nocal.1024.1_1.rdf
RDFOUT_2=99199-8k.nocal.1024.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
NFS server rhyme not responding still trying
NFS server rhyme ok

/usr/local/bin/jurg2spec -i 99199-8k.nocal.1024.1.rdf -o 99199-8k.nocal.1024.rdf -x PRDX.OUT.s15  -p 192 -d 3.5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  394
Total SC spectra:  394
Processing data...

That produced 394 raw spectra--recall there was nearly a 100 sec RTT with
about 10 runs using 2 hops.  Yikes.  Unfortunately, Ray's software doesn't set 
irun correctly, so we need to figure it out and set it using rdftags.  

There are 10 runs.  

Run	Spectra
---	-------
 1	  1- 40
 2	 41- 78
 3	 79-118
 4	119-158
 5	159-196
 6	197-236
 7	237-276
 8	277-314
 9	315-354
10	355-394

This is where things stood on Nov. 9 before we had problems with reason 
when Richard Zinar installed a patch.

file: 99199-8k.nocal.1024.rdf

I had just finished setting irun for the hops when I stopped.  I rechecked them
and they're fine.

Other tags: hops alternate between 1 and 0...
            tsys ch1,2 = 15.2, 16.5 K as usual.  16.5 is very close to the recorded 
            values so let's keep it.  ch1 wasn't recorded but it shouldn't be off
            by more than about a degree, so let's keep it.

I ran this file through tkrdfreduc.  Output of the reduction looks OK: no
errors.  e/m values varied quite a bit but I think that's because the spectra
had only one look/hop.

calibrated file: 99199-8k.1024.rdf       I'll change the name later.

We have about 40 FFTs/run and there are 10 runs.  Good noise statisics.  
dfreq = 0.5 Hz.

I plotted all 10 spectra (both channels) and then aborted part way through
plotting SC.  That generated an error message that I forgot to save.  Now I
can't plot any spectra.  ==> exit tkpl and restart it.

The individual runs look OK, although there's a surprising amount of variability
in the echo strengths--for example, the first run has an OC S/N of about 90 but
the 3rd run is close to 400.  

So the voltage files produced usable spectra even though the PSD files have some
unknown problem.  

I summed the spectra and removed the baseline.  However, the baseline removal
was wrong--it wasn't centered on zero sigma.  It turns out that jsnr1 and jsnr2
weren't set correctly so with such a strong echo the removal was skewed.  Go back
to the file with the runs, reset jsnr1 and 2, and repeat.

I made a plot of the weighted sum.

Target unknown from file ./results.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19  10-oc  02:14:07  00:00:00  02:15:37   0.0   2.00e-03   2.84e+00  3.5e-03  1.5
Target unknown from file ./results.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19  10-sc  02:14:07  00:00:00  02:15:37   0.0   2.17e-03   5.60e-01  3.7e-03  1.4 0.197263 0.198598 0.195929

What's the deal?  This OC xsec is much larger than what I got with the other
CW data from this track.  ???  The previous time I compared voltages with
PSD files was with 1999 GU3 and I got consistent results.  Why is the 
cross section so much larger with this file?

I need to check the OC xsec from at least one other voltage file to see if
the results are consistent.  Perhaps this file is simply corrupted, or maybe
there's something in the tags that I haven't noticed.  Perhaps 500 Hz sampling was
too slow?  Alternatively, there could have been something wrong with the system.

Another option: pick a different FFT and repeat the reduction with this file to 
see if the results are consistent.

Let's try that first, using FFT=8192 as I had originally planned.

reason:/data/ast5/1999JM8/proc/cw < 32 > dofft -d 3.5 -p 192 -f 8192 -i VOLT99199-8k.1999JM8 -o 99199-8k.8192.nocal.rdf -x PRDX.OUT.s15 
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199-8k.1999JM8
RDFOUT_1=99199-8k.8192.nocal.1_1.rdf
RDFOUT_2=99199-8k.8192.nocal.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
NFS server rhyme not responding still trying
NFS server rhyme ok
/usr/local/bin/jurg2spec -i 99199-8k.8192.nocal.1.rdf -o 99199-8k.8192.nocal.rdf -x PRDX.OUT.s15  -p 192 -d 3.5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  31
Total SC spectra:  31
Processing data...

This took quite a bit longer (8 k FFT) than it did when using a 1 k FFT.

There were usually 3 spectra/run so I changed irun accordingly and ran the
uncalibrated file through tkrdfreduc.  I got another rmsc error with the first run.

The individual calibrated spectra are badly corrupted.  They resemble the results 
of the PSD file with lots of weird spikes in both polarizations.  So there's something
wrong with this combination of sampling rate and FFT.  How can we tell while observing?
Imagine that this had been the only cw data that we got--we could have seriously 
mislead ourselves.  

What if the settings on Deff somehow skewed the noise removal...?  Let's do a quick repeat
of the last FFT but with a larger Deff of about 5 km.

reason:/data/ast5/1999JM8/proc/cw < 3 > dofft -d 5.0 -p 192 -f 8192 -i VOLT99199-8k.1999JM8 -o 99199-8k.8192b.nocal.rdf -x PRDX.OUT.s15
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199-8k.1999JM8
RDFOUT_1=99199-8k.8192b.nocal.1_1.rdf
RDFOUT_2=99199-8k.8192b.nocal.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199-8k.8192b.nocal.1.rdf -o 99199-8k.8192b.nocal.rdf -x PRDX.OUT.s15  -p 192 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  31
Total SC spectra:  31
Processing data...

I reset irun again and ran it through tkrdfreduc ==> same result as before.

Let's try again with an intermediate FFT of 4096:

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

1999 November 11

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

Note: I have not been plotting the noise statistics for the CW data thus
far in the JM8 reduction.  I know that many of the spectra from the PSD
files have a rather small number of looks so there will be chi-square noise.
I'll go back to this shortly to check.

- - - - - - - - - - - - - - - - - - - - 

Continuing with the 4096-point FFT:

reason:/data/ast5/1999JM8/proc/cw < 39 > dofft -d 3.5 -p 192 -f 4096 -i VOLT99199-8k.1999JM8 -o 99199-8k.nocal.4096.rdf -x PRDX.OUT.s15
contents of ast_spec control file:
4096,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199-8k.1999JM8
RDFOUT_1=99199-8k.nocal.4096.1_1.rdf
RDFOUT_2=99199-8k.nocal.4096.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199-8k.nocal.4096.1.rdf -o 99199-8k.nocal.4096.rdf -x PRDX.OUT.s15  -p 192 -d 3.5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  88
Total SC spectra:  88
Processing data...

Leave Tsys values alone...  change irun tags appropriately...

file: 99199-8k.nocal.4096.rdf

I ran this through tkrdfreduc.  No errors.  OC e/m values varied 
by a factor of several; SC values were closer to unity.  

Here's an example of the final tkrdfreduc output for the SC channel:

rnb.Calibrate():  xmit_sta is DSS14     Default value used                    
Using Observatory Gain Constant:  1.11452e+07
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
(  0)    1.11452e+07   98.6  16.5   673.694    425         2   0.12207     81.92   0.57735  0.00427794
(  1)    1.11452e+07  98.58  16.5   674.473    425         2   0.12207    65.536  0.447214  0.00330797
(  2)    1.11452e+07  98.57  16.5   675.069    425         2   0.12207    73.728  0.447214  0.00330331
(  3)    1.11452e+07  98.56  16.5   675.688    425         2   0.12207    73.728   0.57735  0.00425839
(  4)    1.11452e+07  98.54  16.5   676.537    425         2   0.12207    65.536  0.447214  0.00329256
(  5)    1.11452e+07  98.53  16.5   677.178    425         2   0.12207    73.728  0.447214  0.00328772
(  6)    1.11452e+07  98.52  16.5   677.842    425         2   0.12207    73.728   0.57735  0.00423802
(  7)    1.11452e+07   98.5  16.5   678.758    425         2   0.12207    65.536  0.447214  0.00327651
(  8)    1.11452e+07  98.49  16.5   679.443    425         2   0.12207    73.728  0.447214  0.00327149
(  9)    1.11452e+07  98.48  16.5    680.15    425         2   0.12207    73.728   0.57735  0.00421684

output file, blocked into runs: 99199-8k.4096.rdf

I got much better looking spectra for each run, but the drastic difference in SNR
in runs 3 and 8 relative to the others still stands out.  So these spectra aren't
full of gibberish but they do have plenty of chi-square noise since there are only
8-10 looks/run.  

One obvious question: are those spikes real?  On two of the spectra they are at
the several hundred sigma level.  

jsnr1 and 2 were off--only the negative echo edge was in the window.  Change 
jsnr1,2 = 1032,1046.  Means the baseline removal might have been off...actually,
it looks pretty good.  

Here's a t87 listing for each run:

Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.4096.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-oc  01:44:05  00:00:00  01:45:35   0.0   3.94e-03   1.84e+00  1.2e-02  1.1
  2   1  1999/07/19   2-oc  01:47:40  00:00:00  01:48:58   0.0   3.05e-03   3.45e+00  9.8e-03  1.3
  3   2  1999/07/19   3-oc  01:50:49  00:00:00  01:52:19   0.0   3.04e-03   7.52e+00  8.2e-03  0.9
  4   2  1999/07/19   4-oc  01:54:09  00:00:00  01:55:35   0.0   3.92e-03   3.45e+00  1.1e-02  0.9
  5   3  1999/07/19   5-oc  01:57:42  00:00:00  01:58:56   0.0   3.03e-03   2.29e+00  8.9e-03  1.0
  6   3  1999/07/19   6-oc  02:00:51  00:00:00  02:02:17   0.0   3.03e-03   3.37e+00  9.6e-03  1.2
  7   4  1999/07/19   7-oc  02:04:11  00:00:00  02:05:37   0.0   3.90e-03   3.89e+00  1.1e-02  0.9
  8   4  1999/07/19   8-oc  02:07:39  00:00:00  02:08:57   0.0   3.02e-03   3.99e+00  5.6e-03  0.4
  9   5  1999/07/19   9-oc  02:10:51  00:00:00  02:12:17   0.0   3.01e-03   4.48e+00  9.2e-03  1.1
 10   5  1999/07/19  10-oc  02:14:11  00:00:00  02:15:37   0.0   3.88e-03   4.57e+00  1.0e-02  0.8
Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.4096.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-sc  01:44:05  00:00:00  01:45:35   0.0   4.28e-03   7.25e-01  1.1e-02  0.9 0.394963 0.401674 0.388286
  2   1  1999/07/19   2-sc  01:47:40  00:00:00  01:48:58   0.0   3.31e-03   1.04e+00  9.2e-03  1.0 0.301128 0.303941 0.298319
  3   2  1999/07/19   3-sc  01:50:49  00:00:00  01:52:19   0.0   3.30e-03   6.69e-01  9.1e-03  0.9 0.0889294 0.0901492 0.0877097
  4   2  1999/07/19   4-sc  01:54:09  00:00:00  01:55:35   0.0   4.26e-03   7.46e-01  1.2e-02  1.0 0.215859 0.219413 0.21231
  5   3  1999/07/19   5-sc  01:57:42  00:00:00  01:58:56   0.0   3.29e-03   9.03e-01  9.4e-03  1.0 0.394702 0.399075 0.390341
  6   3  1999/07/19   6-sc  02:00:51  00:00:00  02:02:17   0.0   3.29e-03   6.88e-01  1.0e-02  1.1 0.204367 0.207392 0.201345
  7   4  1999/07/19   7-sc  02:04:11  00:00:00  02:05:37   0.0   4.24e-03   1.00e+00  9.7e-03  0.6 0.258049 0.260653 0.255449
  8   4  1999/07/19   8-sc  02:07:39  00:00:00  02:08:57   0.0   3.28e-03   5.03e-01  9.7e-03  1.1 0.126172 0.12861 0.123734
  9   5  1999/07/19   9-sc  02:10:51  00:00:00  02:12:17   0.0   3.27e-03   9.09e-01  9.7e-03  1.1 0.203047 0.205247 0.200849
 10   5  1999/07/19  10-sc  02:14:11  00:00:00  02:15:37   0.0   4.22e-03   8.66e-01  1.2e-02  1.0 0.189539 0.19225 0.186831

Yikes.  The variations in the cross sections and the ratios are enormous.

rows    irun    gain
--------------------
   1     1.0   673.7
   2     2.0   674.5
   3     3.0   675.1
   4     4.0   675.7
   5     5.0   676.5
   6     6.0   677.2
   7     7.0   677.8
   8     8.0   678.8
   9     9.0   679.4
  10    10.0   680.1

Those gains are comparable with other results from the same day:

file: 99199-4k.runs.rdf 
rows    irun    gain
--------------------
   1     1.0   691.6

file: 99199-16k.runs.vig.rdf
rows    irun    gain
--------------------
   1     3.0   691.0
   2     4.0   690.6
   3     5.0   690.3
   4     6.0   690.0
   5     7.0   689.7
   6     8.0   689.3

file 99199B.runs.rdf
rows    irun    gain
--------------------
   1     1.0   653.4
   2     2.0   652.4
   3     3.0   651.0

==> The problem doesn't appear to be with the gains.  

Perhaps there's something wrong with sampling at only 500 Hz?  In 
the future, be sure to go with at least 1000 Hz sampling.

Printing the t87 listing by runs was a pain: hitting the text output
"print" button generated an error message stating "pl: A file-type must be specified."
So I copied the text into emacs, hit print, and got the same message (I hadn't saved
the file yet).  Then I saved the file and used enscript:

reason:/data/ast5/1999JM8/proc/cw < 7 > enscript -1 -f Courier7 -r 99199-8k.4096.runs.t87 

**
** The data in files PSD99199-8.1999JM8 and VOLT99199-8k.1999JM8 are suspect
** so let's throw it out.
**

- - - - - - - - - - - - - - - - - - - - - 

Return to the CW bandwidths.

DOY 201
-------

dfreq = 0.244 Hz

I discovered that the background removal may have been wrong--jsnr1,2 were set so that
some very strong echo points were outside the window in the file blocked by
runs.  I didn't notice this before so the summed values are incorrect.

Change jsnr1,2 from 509,516->503,520 and then repeat the sum & baseline removal.

Resaved into 99201.sum.rdf

Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   2-oc  02:34:52  02:35:09  02:36:30   0.0   2.29e-03   2.09e+00  6.3e-03  1.8
Target 1999JM8                     from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   2-sc  02:34:52  02:35:09  02:36:30   0.0   2.17e-03   3.64e-01  5.8e-03  1.7 0.174023 0.176824 0.171224

These results didn't change.  Perhaps the baseline removal before was OK.

Echo power:

rows 505 506 507 508 509 510 511 512 513 514 515 516
----------------------------------------------------
   1   2   4  27  79 115 133 155 123 169  78  19   4

rows 505 506 507 508 509 510 511 512 513 514 515 516
----------------------------------------------------
   1  -0   2   8  22  29  11  36  24  23  10   2   1

There are 9 points with OC power > 19 sigma, or (8)*(0.244 Hz/bin) = 2.0 Hz.

Here's the breakdown into the two runs:

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-oc  02:31:52  02:32:09  02:33:22   0.0   3.24e-03   1.63e+00  8.6e-03  1.7
  2   1  1999/07/20   2-oc  02:34:52  02:35:09  02:36:30   0.0   3.24e-03   2.57e+00  8.3e-03  1.6
Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99201.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-sc  02:31:52  02:32:09  02:33:22   0.0   3.07e-03   2.81e-01  8.5e-03  1.9 0.172187 0.177469 0.166914
  2   1  1999/07/20   2-sc  02:34:52  02:35:09  02:36:30   0.0   3.07e-03   4.73e-01  8.0e-03  1.7 0.184168 0.187332 0.181008

That's A LOT of variability from one run to the next.  

- - - - - - - - - - 

DOY 201
-------

1 run, 0.244 Hz resolution

file: 99202.runs.rdf

Here's how things look:

rows 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525   sdev   jsnr1   jsnr2
-------------------------------------------------------------------------------------------
   1   1   3   6  36 172  95 192 282 104  21   6   1   1   1   2   1 0.0027   510.0   520.0

rows 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525   sdev   jsnr1   jsnr2
-------------------------------------------------------------------------------------------
   1  -1   1   2  29  16  37  28  26  26   3   0   0   1   1   1   2 0.0025   510.0   520.0

change jsnr2 -> 521.

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-oc  17:41:21  17:41:01  17:42:54   0.0   2.66e-03   2.45e+00  6.0e-03  1.2
Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99202.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-sc  17:41:21  17:41:01  17:42:54   0.0   2.49e-03   4.17e-01  6.2e-03  1.5 0.170421 0.172974 0.167871

Adjusting jsnr2 increased OCxsec slightly, but we'll cover for that by 
assigning an appropriately large uncertainty.  

Bandwidth: 6 bins with SNR > 20 sigma, so 5(0.244) = 1.2 Hz, one full Hz smaller 
than my earlier estimate.  

- - - - - - - - - - 

DOY 204 (July 23)
------------------

1 run, 0.244 Hz resolution.

rows1020102110221023102410251026102710281029103010311032103310341035   jsnr1   jsnr2    sdev
--------------------------------------------------------------------------------------------
   1   1   0  15  50 214 188 321 101 135  53   9   8   1   4  -0   1  1020.0  1035.0 0.00185

rows1020102110221023102410251026102710281029103010311032103310341035   jsnr1   jsnr2    sdev
--------------------------------------------------------------------------------------------
   1  -1   1   3   3  31  42  54  24  33  10   1   2   1   0   2  -1  1020.0  1035.0 0.00201

jsnr1 and 2 are rather wide, so the OCxsec will include sincx^2 effects,
but that's small compared with the assigned standard errors of ~25%.

Bandwidth: use points with > 10 sigma => (7)*(0.244 Hz/bin) = 1.7 Hz

Target 1999JM8             from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-oc  00:36:44  00:37:14  00:37:59   0.0   1.85e-03   2.03e+00  4.4e-03  1.4
Target 1999JM8             from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-sc  00:36:44  00:37:14  00:37:59   0.0   2.01e-03   4.14e-01  4.8e-03  1.4 0.203447 0.205839 0.201056

- - - - - - - - - - 

DOY 205 (July 24)
------------------

2 runs, 0.244 Hz resolution.

Earlier I found that the first run is bad.  

99205.runs2.rdf  Good file: has the one good run
99205.runs.rdf   Has the two runs: one good, one bad
99205.sum.rdf    corrupted ==> I deleted it.

reason:/data/ast5/1999JM8/proc/cw < 10 > mv 99205.runs.rdf 99205.badruns.rdf
reason:/data/ast5/1999JM8/proc/cw < 11 > mv 99205.runs2.rdf 99205.goodrun.rdf

 > enscript -1 -f Courier9 -r 99205.t87  <== Use Courier 9 printed in landscape

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    1    2    7    3    8   41  110  141  312  397  323  171  122   19    8    8    0    4  0.0015  1019.0  1034.0

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    0    3   -0   -1    0   11   16   85   48   91   64   23    6    1    3    1    1    0  0.0016  1019.0  1034.0

Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99205.goodrun.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   2-oc  17:00:38  17:01:08  17:01:53   0.0   1.50e-03   2.51e+00  3.8e-03  1.6
Target 1999JM8                 from file /data/ast5/1999JM8/proc/cw/99205.goodrun.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   2-sc  17:00:38  17:01:08  17:01:53   0.0   1.57e-03   5.51e-01  3.6e-03  1.3 0.21987 0.221363 0.218378

bandwidth: (8)*(0.244 Hz/bin) = 2.0 Hz

No changes to jsnr1,2 from last time.  

(I'm making hardcopies of t87 listings and echo points as I go back
through the CW data.)

- - - - - - - - - - 

DOY 208 (July 27)
-----------------

Here's how things stand with the two runs:

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    2    3    6    5   26   62  103  304  123   82   98   57   48   45   20    1    3    2  0.0011  1021.0  1028.0
   2    1    2   12    3   13   75  126  302  116  182  299  110  134   64   74    4    5    0  0.0010  1021.0  1028.0

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    1    2    1    3    0   22   18   14   28   48   14   13   17   11    0    0   -0   -0  0.0012  1021.0  1028.0
   2    1   -0    0    1    3   14   13   19   65   21   27   30   17   13    6    3   10   -1  0.0011  1021.0  1028.0

Change jsnr2 -> 1033.

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    2    3    6    5   26   62  103  304  123   82   98   57   48   45   20    1    3    2  0.0011  1021.0  1033.0
   2    1    2   12    3   13   75  126  302  116  182  299  110  134   64   74    4    5    0  0.0010  1021.0  1033.0

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    1    2    1    3    0   22   18   14   28   48   14   13   17   11    0    0   -0   -0  0.0012  1021.0  1033.0
   2    1   -0    0    1    3   14   13   19   65   21   27   30   17   13    6    3   10   -1  0.0011  1021.0  1033.0

Target 1999JM8               from file /data/ast5/1999JM8/proc/cw/99208.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-oc  01:30:58  01:31:01  01:32:13   0.0   1.10e-03   1.07e+00  2.8e-03  1.6
  2   1  1999/07/27   2-oc  01:33:01  01:33:20  01:34:20   0.0   1.01e-03   1.51e+00  2.8e-03  1.9
Target 1999JM8               from file /data/ast5/1999JM8/proc/cw/99208.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-sc  01:30:58  01:31:01  01:32:13   0.0   1.18e-03   2.26e-01  3.2e-03  1.8 0.21005 0.213089 0.207014
  2   1  1999/07/27   2-sc  01:33:01  01:33:20  01:34:20   0.0   1.08e-03   2.51e-01  2.9e-03  1.7 0.16547 0.167397 0.163543

I summed the spectra, removed the baseline with a 1st order polynomial,
and then saved the results to 99208.sum.rdf (overwriting the old file).

Summed results:

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    1    3   12    5   26   96  162  427  168  189  286  119  130   77   67    2    5    1  0.0007  1021.0  1033.0

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    1    0    0    2    2   24   21   23   66   47   29   30   24   17    4    2    6   -1  0.0008  1021.0  1033.0

Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   2-oc  01:33:01  01:33:20  01:34:20   0.0   7.45e-04   1.31e+00  2.1e-03  1.9
Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   2-sc  01:33:01  01:33:20  01:34:20   0.0   7.98e-04   2.33e-01  2.2e-03  1.9 0.178118 0.179851 0.176387

The OCxsec and SC/OC haven't changed.  

bandwidth: there are 11 contiguous Doppler cells with S/N > 10 sigma, so 
(10)*(0.244 Hz/bin) = 2.4 Hz.  

- - - - - - - - - - - - - - - - - - - - - 

DOY 209 (July 28)
-----------------

1 run, 0.24 Hz resolution.  Should have done at least 3 runs for better statistics.

file: 99209.runs.rdf

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    5   12   72  254  571  367 2005  428  410  311  806  373  194   46    6    2    1    1  0.0007  1015.0  1035.0

rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035    sdev   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1    2    4    6   43   81   35   61   94  106   53   45   57   73   21    1    2    3    2  0.0008  1015.0  1035.0

Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-oc  17:14:17  17:14:14  17:15:14   0.0   7.44e-04   4.37e+00  1.8e-03  1.4
Target 1999JM8                   from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-sc  17:14:17  17:14:14  17:15:14   0.0   8.01e-04   5.60e-01  2.6e-03  2.5 0.128067 0.128656 0.127478

bandwidth: there are 13 Doppler bins with echo power > 10 sigma, so
(12)*(0.244 Hz/bin) = 2.9 Hz.  So my previous estimate was OK.  

The jsnr1,2 bounds are a bit generous but acceptable.  The OC xsection is hard to 
believe, though, because it dwarfs the cross sections obtained on the other days.
However, the bandwidth on this day was the largest to date so it's conceivable that
the cross section is valid (this was the "twin peaks" day).  I'm going to compare 
the OCxsections with the maximum delay extents too to check for correlations.

However, let's take a closer look at the tags for DOY 209. 
There are only 9 looks in this spectrum, so the self noise is harsh: 33%.
Tsys = 15.9, 17.1... no gross problems there... gain: 658*10^12, so that's 
an acceptable value.  Maybe the bad noise statistics are skewing sdev?  

Check the noise statistics: clearly chi-squared.  I made a plot and printed it.
I'll discuss this with Steve tomorrow.  

Let's try interpolating across the one really big point to see how that affects
the cross section (the one point is like a delta function).  The point in question
has SNR = 2005.  Adjacent points have SNR = 367 and 428, so take their average:
(367 + 428)/2 = 398 and subtract that from 2005: 2005-398 = 1607 sigma.
Radar cross section of the spike: (1607)*(7.44E-4 km^2/sdev) = 1.2 km^2.  
So even if we interpolate across the spike the OC xec on that day was > 3 km^2;
thus, it would still be the largest of any day.  As noted above, that's consistent
with the bandwidth.  

If the chi-square noise is a factor in sdev for this spectrum, it will be on
many other days.  I can always recompute the spectrum using dofft with a coarse
FFT to put the echo power into one Doppler cell with much better noise
statistics.  From my experience with 1999 GU3, however, where I got consistent
results regardless of the FFT, perhaps we shouldn't expect much of a change.

==> Check it out: go into the voltage file and try a new FFT = 512 and
see what happens.  That will provide 1 look every 0.5 seconds for about 100 
per run.  

reason:/data/ast5/1999JM8/proc/cw < 16 > dofft -d 3.5 -p 192 -f 512 -i VOLT99209.1999JM8 -o 99209.nocal.512.rdf -x PRDX.OUT.s15
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99209.1999JM8
RDFOUT_1=99209.nocal.512.1_1.rdf
RDFOUT_2=99209.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99209.nocal.512.1.rdf -o 99209.nocal.512.rdf -x PRDX.OUT.s15  -p 192 -d 3.5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  80
Total SC spectra:  80
Processing data...

tsys = 15.6, 16.7.  The other file (calibrated) used 
15.9 and 17.1, which is close enough that I'm not going to change tsys.

trpwr = 0.  Change that to: 445 kW

file: 99209.nocal.512.rdf

Run this through tkrdfreduc...looks OK.  

file: 99209.512.rdf

Here's how things look:

rows  120  121  122  123  124  125  126  127  128  129  130  131  132  133  134  135   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------
   1    1    5    3    3    2    5   11   21  141 1102  215   22    9    5    2    2   128.0   129.0

rows  120  121  122  123  124  125  126  127  128  129  130  131  132  133  134  135   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------
   1    1   -2   -0    0    0    2   -0    4   22  161   45    4    6    0    0   -0   128.0   129.0

Echo is still very strong but the peak SNR is way down relative to the 
spectra with 0.244 Hz resolution.  

Change jsnr1,2 -> 124,134.  Note that we still have significant tails due
to (sincx)^2.  

Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-oc  17:14:29  00:00:00  17:15:14   0.0   1.97e-03   3.02e+00  2.7e-03  3.6
Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-sc  17:14:29  00:00:00  17:15:14   0.0   2.11e-03   5.15e-01  3.0e-03  4.1 0.170468 0.171487 0.169449

So the OC xsec changed substantially: from 4.4 km^2 with 4096 point FFT
to 3.0 km^2 with a 512 point FFT.  Well, well, well...  That means I 
need to do this for the other spectra with only a few looks.  Note that
this is still the largest OC xsec.  The variation relative to the previous
day is more than a factor of two.  

I think a good strategy would be to recalibrate the data using the same 
short FFT on those days when we sampled at 1 kHz.  

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

1999 November 18 & 19

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

Get noise histograms from DOY 209: 99209.512.rdf

Using current values of jsnr1 and jsnr2, the (sincx)^2 response is skewing the noise
statistics a bit, but otherwise the noise is much closer to gaussian.  

I made a figure and put it in the notebook.  There are 80 looks.  
file: 99209.512.noise.tpl

loading the file 99209.tpl back into tkpl causes the program to bomb.  

- - - - - - - - - - 

Two points: 

1. Check the noise statistics for all the reduced PSD files

2. Repeat the JM8 cw reductions using dofft and a coarser FFT

A quick check of DOY 212 showed that the background removal with the PSD file was off.
That could have resulted because the echoes were so strong and it may have affected
the OCxsec.  Gotta be more careful...

99212.sum.4096.noise.tpl: bad background removal
99213.sum.4096.noise.tpl: same problem.  

- - - - - - - - - - - - - - - - - - - - 

I just noticed that the DOY 209 dofft reduction above used the wrong PRDX file.  That
shouldn't make much of a difference but let's check to be sure.

reason:/data/ast5/1999JM8/proc/cw < 20 > dofft -d 5.0 -p 192 -f 512 -i VOLT99209.1999JM8 -o 99209.nocal.512.new.rdf -x PRDX.OUT.s23
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99209.1999JM8
RDFOUT_1=99209.nocal.512.new.1_1.rdf
RDFOUT_2=99209.nocal.512.new.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99209.nocal.512.new.1.rdf -o 99209.nocal.512.new.rdf -x PRDX.OUT.s23  -p 192 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  80
Total SC spectra:  80
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 21 > 

Note that I used D = 5.0 km instead of 3.5.

change trpwr -> 445.

80 looks

Change jsnr1, 2 = 124, 134

rows  125  126  127  128  129  130  131  132  133  134  135   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    5   11   21  141 1102  215   22    9    5    2    2   124.0   134.0

rows  125  126  127  128  129  130  131  132  133  134  135   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    2   -0    4   22  161   45    4    6    0    0   -0   124.0   134.0

Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.new.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-oc  17:14:29  00:00:00  17:15:14   0.0   1.97e-03   3.02e+00  2.7e-03  3.6
Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.new.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-sc  17:14:29  00:00:00  17:15:14   0.0   2.11e-03   5.15e-01  3.0e-03  4.1 0.170468 0.171487 0.169449

No change, as expected.

DOY 212 
=======

Use dofft with FFT = 512

reason:/data/ast5/1999JM8/proc/cw < 22 > dofft -d 5.0 -p 192 -f 512 -i VOLT99212.1999JM8 -o 99212.nocal.512.rdf -x PRDX.OUT.s23
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99212.1999JM8
RDFOUT_1=99212.nocal.512.1_1.rdf
RDFOUT_2=99212.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99212.nocal.512.1.rdf -o 99212.nocal.512.rdf -x PRDX.OUT.s23  -p 192 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  180
Total SC spectra:  180
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 23 > 

tags look OK... 

One minor tag issue of concern: posfr = -1 but the spectra have seemed OK.  According to 
Keith's tag description posfr = -1 is supposed to mean that freq increases from right to left.

Also, all the irun values equal one ==> everything will get summed into one spectrum (there
are two runs).  That's fine.  

run it through the calibration...

file: 99212.512.rdf

There are 180 looks.  Noise statistics should be excellent.  

change jsnr1,2 = 124, 134.  That's wide enough to include (sincx)^2 effects,
but they don't contribute much because the powers are so low.  I set jsnr1 and
2 to include them so as not to skew the noise histograms.

Target unknown from file /data/ast5/1999JM8/proc/cw/99212.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/31   1-oc  17:01:12  00:00:00  17:04:03   0.0   1.52e-03   1.94e+00  2.3e-03  4.5
Target unknown from file /data/ast5/1999JM8/proc/cw/99212.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/31   1-sc  17:01:12  00:00:00  17:04:03   0.0   1.63e-03   4.25e-01  2.5e-03  4.6 0.219443 0.220766 0.21812

OC xsec = 1.9 km^2
SC/OC   = 0.22 +/- 0.01

Previously I got OCxsec = 2.6 km^2.  and SC/OC =0.20.

DOY 213
=======

reason:/data/ast5/1999JM8/proc/cw < 9 > dofft -d 5.0 -p 192 -f 512 -i VOLT99213.1999JM8 -o 99213.nocal.512.rdf -x PRDX.OUT.s23
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99213.1999JM8
RDFOUT_1=99213.nocal.512.1_1.rdf
RDFOUT_2=99213.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99213.nocal.512.1.rdf -o 99213.nocal.512.rdf -x PRDX.OUT.s23  -p 192 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  192
Total SC spectra:  192
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 10 > 

Tsys ch1,2 = 15.1, 16.1 K.  For this pass, let's leave these alone and check
for significant differences relative to previous values.

all the irun values = 1, but that's fine since I was going to sum anyway.

192 looks.

The usual (sincx)^2 effect is present.  

jsnr1,2 = 128,129.  Change to 124,134
An alternative would be to smooth optimally in freq and then read the 
echo power from the peak point and multiply it by sdev.

rows  120  121  122  123  124  125  126  127  128  129  130  131  132  133  134  135  136  137  138  139  140   jsnr1   jsnr2
-----------------------------------------------------------------------------------------------------------------------------
   1    1   -0    3    4    5    5   12   23  189  767  108   27   12    5    3    3    3   -1    1    1    1   124.0   134.0

rows  120  121  122  123  124  125  126  127  128  129  130  131  132  133  134  135  136  137  138  139  140   jsnr1   jsnr2
-----------------------------------------------------------------------------------------------------------------------------
   1    1    0   -1   -0    1    1    4    6   46  165   23    1    1    3    1    3   -0    0   -0    2    0   124.0   134.0

Target unknown from file /data/ast5/1999JM8/proc/cw/99213.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/08/01   1-oc  12:03:22  00:00:00  12:06:16   0.0   1.39e-03   1.61e+00  2.0e-03  4.1
Target unknown from file /data/ast5/1999JM8/proc/cw/99213.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/08/01   1-sc  12:03:22  00:00:00  12:06:16   0.0   1.48e-03   3.73e-01  2.2e-03  4.2 0.232503 0.233877 0.23113

OCxsec = 1.6 km^2
SC/OC  = 0.23+/-0.01

Well, well, well... Recall that SC/OC before (0.24 Hz res'n) was 0.30
and that OCxsec was 2.6 km^2.  Yikes...    

DOY 208 (July 27)
=================

reason:/data/ast5/1999JM8/proc/cw < 10 > dofft -d 5 -p 192 -f 512 -i VOLT99208.1999JM8 -o 99208.nocal.512.rdf -x PRDX.OUT.s21 
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99208.1999JM8
RDFOUT_1=99208.nocal.512.1_1.rdf
RDFOUT_2=99208.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99208.nocal.512.1.rdf -o 99208.nocal.512.rdf -x PRDX.OUT.s21  -p 192 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  216
Total SC spectra:  216
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 11 > 

Tsys: ch1,2 = 15.4, 16.5.  Leave as is--difference is at the ~10% level, which
is less than the standard errors we'll adopt.  

irun = 1 => put all the hops into one sum.

The rest of the reduction was uneventful...

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2    sdev
-----------------------------------------------------------------------------------
   1    3    0    2    7   19  383  131    9    2    3    4   126.0   132.0 0.00161

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2    sdev
-----------------------------------------------------------------------------------
   1    1   -1    0    1    5   68   18    2   -1   -2    0   126.0   132.0 0.00173

Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-oc  01:31:16  00:00:00  01:34:22   0.0   1.61e-03   8.89e-01  2.2e-03  3.6
Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-sc  01:31:16  00:00:00  01:34:22   0.0   1.73e-03   1.62e-01  2.3e-03  3.5 0.181996 0.18462 0.179373

What???  0.89 km^2?  What makes that hard to believe is the value of 3.0 km^2 on
the next day.  Then again...on DOY 208 the most pointed end was oriented toward
the radar, so it's conceivable that there was less projected area to reflect.  
Geographos comes to mind, but even that object had OCxsec variations of only a 
factor of two, not three.   Something wrong with the DOY 209 data?

Tsys could be a factor: the values I used before were 18.2 and 19.5, which are
about 3 K warmer than the tags.  That's a difference of almost 20%, so let's split
the file into 2 polarizations, change Tsys, combine them, and then repeat the
reduction of the nocal file.

reason:/data/ast5/1999JM8/proc/cw < 17 > rdfseparate -i 99208.nocal.512.rdf -o 99208.nocal.512.sep
Dumping frame 1 to 99208.nocal.512.sep001.rdf
Dumping frame 2 to 99208.nocal.512.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 18 > cat 99208.nocal.512.sep001.rdf 99208.nocal.512.sep002.rdf > 99208.nocal.512.corrected.rdf

Here's the result:

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2    sdev
-----------------------------------------------------------------------------------
   1    3    0    2    7   19  383  131    9    2    3    4   126.0   132.0 0.00190

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2    sdev
-----------------------------------------------------------------------------------
   1    1   -1    0    1    5   68   18    2   -1   -2    0   126.0   132.0 0.00204

Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-oc  01:31:16  00:00:00  01:34:22   0.0   1.90e-03   1.05e+00  2.6e-03  3.6
Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-sc  01:31:16  00:00:00  01:34:22   0.0   2.04e-03   1.91e-01  2.7e-03  3.5 0.181193 0.183806 0.178583

OCxsec = 1.1 km^2, SC/OC = 0.18.
Value I recorded from 0.244 Hz spectrum was 1.3 km^2.

I spoke with Steve: he thinks I'm spending too much time on this relative to what we can
get out of it due to the bad calibration of the Goldstone system.  So go with our best
estimates, and when it comes time to hand everything to Scott, let him know the standard
errors and my best estimate of what was really going on.  If there were bad days, flag
them.

So: Wrap up the OCxsecs using short FFTs and then move on.

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

                        1999 November 21

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

Continuing with reducing the CW data with short FFTs...

DOY 205 (July 24)
=================

reason:/data/ast5/1999JM8/proc/cw < 12 > dofft -d 5 -p 192 -f 512 -i VOLT99205.1999JM8 -o 99205.nocal.512.rdf -x PRDX.OUT.s21
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99205.1999JM8
RDFOUT_1=99205.nocal.512.1_1.rdf
RDFOUT_2=99205.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99205.nocal.512.1.rdf -o 99205.nocal.512.rdf -x PRDX.OUT.s21  -p 192 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  236
Total SC spectra:  236
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 13 > 

Tsys: ch1,2 = 7.1, 17.9

ch1 should be 17.1, not 7.1.  

reason:/data/ast5/1999JM8/proc/cw < 14 > rdfseparate -i 99205.nocal.512.rdf -o 99205.nocal.512.sep
Dumping frame 1 to 99205.nocal.512.sep001.rdf
Dumping frame 2 to 99205.nocal.512.sep002.rdf
reason:/data/ast5/1999JM8/proc/cw < 15 > 

reason:/data/ast5/1999JM8/proc/cw < 15 > cat 99205.nocal.512.sep001.rdf 99205.nocal.512.sep002.rdf > 99205.nocal.512.corrected.rdf

tags look OK, but I'm still puzzled that posfr = -1.

Ran this through tkrdfreduc: 99205.512.rdf

No obvious problems with the calibration.

236 looks.

change jsnr1,2 from 128,129->126,132:

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    5    3    3   13   21  838  141   14    5    3    4   126.0   132.0

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2
---------------------------------------------------------------------------
   1   -1    0    2    2    7  125   26    8    2    1    0   126.0   132.0

Target unknown from file /data/ast5/1999JM8/proc/cw/99205.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   1-oc  16:58:26  00:00:00  17:01:53   0.0   2.69e-03   2.78e+00  3.3e-03  2.9
Target unknown from file /data/ast5/1999JM8/proc/cw/99205.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   1-sc  16:58:26  00:00:00  17:01:53   0.0   2.81e-03   4.80e-01  3.8e-03  3.5 0.172968 0.174337 0.171599

OCxsec is LARGER with FFT=512 than before: previous result was 2.5 km^2

Ratio has dropped from 0.22 -> 0.18

This spectrum has more positive noise points than I expected given the number of
looks.  Some are due to sincx^2, but what about the rest?  It doesn't look as
if the background removal is bad...  Nor is this an issue of the number of
histogram bins (30 in most cases).  

DOY 204 (July 23)
=================

reason:/data/ast5/1999JM8/proc/cw < 16 > dofft -d 5 -p 192 -f 512 -i VOLT99204.1999JM8 -o 99204.nocal.512.rdf -x PRDX.OUT.s21
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99204.1999JM8
RDFOUT_1=99204.nocal.512.1_1.rdf
RDFOUT_2=99204.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99204.nocal.512.1.rdf -o 99204.nocal.512.rdf -x PRDX.OUT.s21  -p 192 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  132
Total SC spectra:  132
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 17 > 

Tsys: ch1,2 = 15.1, 16.4.  These are the actual temps at the start, so 
they're OK.

The remainder of the reduction looks OK.

132 looks

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1    0    1    2    5  361   26    7    3    0    2   126.0   132.0

rows  124  125  126  127  128  129  130  131  132  133  134   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1   -1    0    0    1   58    4    1   -1    1    0   126.0   132.0

Target unknown from file /data/ast5/1999JM8/proc/cw/99204.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-oc  00:36:50  00:00:00  00:38:01   0.0   5.22e-03   2.11e+00  5.8e-03  2.4
Target unknown from file /data/ast5/1999JM8/proc/cw/99204.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-sc  00:36:50  00:00:00  00:38:01   0.0   5.67e-03   3.64e-01  6.3e-03  2.4 0.172219 0.175225 0.169215

OCxsec = 2.1 km^2, SC/OC = 0.17.  Previous values: 2.0 km^2, 0.20

The noise statistics are puzzling: there seem to be far fewer SC points
than OC.  ??  Is there something wrong with the filter?  In both plots
I used bins = 30.

I've had tkpl hang twice while I've been trying to figure out this problem.
Both times I entered '1' for the spectrum number instead of zero.  Recall that
the noise plotting filter counts from zero instead of 1.  When I enter 1 
I've gotten an error message that jsnr1 must be less than jsnr2, which, 
of course, it is.

Here's what happened when I tried running this from the command line:

reason:/data/ast5/1999JM8/proc/cw < 34 > rdfnoisehist -i 99204.512.rdf -o junk -f 1 -a -n 3
rdfnoisehist: unrecognized option `-o'
Usage:  rdfnoisehist -i infile -o outfile [-f frame] [-r r_start -R r_end]|[-s index [-s index...]]|[-a] [-n nbins] [-h]

-i   infile          specifies the name of the input file,
                     a '-' implies the use of stdin
-f   frame           Use data from the specified frame only
-r   r_start         Set the start of a range of spectra to plot.
-R   r_end           Set the end of a range of spectra to plot.
-s   index           Plot a single spectrum.  May be used more
                     than once on the command line to specify
                     a non-contiguous set of spectra.
-a                   Plot every spectrum.
-n   bins            Use this number of bins for counting data
-h                   help
reason:/data/ast5/1999JM8/proc/cw < 35 > 

==> I added this to a list of software problems that I'm going to send to Keith
    and Mike Thomas.

DOY 202 (July 21)
=================

reason:/data/ast5/1999JM8/proc/cw < 20 > dofft -d 5.0 -p 192 -f 512 -i VOLT99202.1999JM8 -o 99202.nocal.512.rdf -x PRDX.OUT.s19
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99202.1999JM8
RDFOUT_1=99202.nocal.512.1_1.rdf
RDFOUT_2=99202.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99202.nocal.512.1.rdf -o 99202.nocal.512.rdf -x PRDX.OUT.s19  -p 192 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  140
Total SC spectra:  140
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 21 > 

4 hops this time, not 2

From above: "We measured Ch1 = 17.8 and Ch2 = 19.0 on point."

Use rdfseparate again to change Tsys:

reason:/data/ast5/1999JM8/proc/cw < 21 > rdfseparate -i 99202.nocal.512.rdf -o 99202.nocal.512.sep
Dumping frame 1 to 99202.nocal.512.sep001.rdf
Dumping frame 2 to 99202.nocal.512.sep002.rdf
reason:/data/ast5/1999JM8/proc/cw < 22 > 

reason:/data/ast5/1999JM8/proc/cw < 22 > cat 99202.nocal.512.sep001.rdf 99202.nocal.512.sep002.rdf > 99202.nocal.512.corrected.rdf

run this the rest of the way through...

Got the calibration error again:

rnb.removeBackground()  status:  Normalizing spectrum 0 with rmsc of 0.166667
rnb.Calibrate():  xmit_sta is DSS14     Default value used        
Using Observatory Gain Constant:  1.11452e+07
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
rnb.Calibrate() error:  rmsc is not what it should be (0.166667) 
                        setting rmsc to 0.09759
(  0)    1.11452e+07   83.9    19   675.569    425         4   1.95312     71.68   0.09759  0.00696483
All Finished!   :^)

140 looks.

This is where things stand before changing jsnr1 and 2:

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1    0    4    5   11  180  100   11    3    3   -0    64.0    65.0

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1   -0   -0    0    2   42   18    2   -0    0    1    64.0    65.0

This might have affected background removal.  

Change jsnr1,2 = 62,69.  There's still some (sincx)^2 in the spectrum.

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1    0    4    5   11  180  100   11    3    3   -0    62.0    69.0

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1   -0   -0    0    2   42   18    2   -0    0    1    62.0    69.0

Target unknown from file /data/ast5/1999JM8/proc/cw/99202.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-oc  17:41:37  00:00:00  17:42:56   0.0   6.52e-03   2.07e+00  1.0e-02  4.6
Target unknown from file /data/ast5/1999JM8/proc/cw/99202.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-sc  17:41:37  00:00:00  17:42:56   0.0   6.96e-03   4.46e-01  9.9e-03  3.9 0.21545 0.220329 0.210582

The new radar cross section has changed from 2.5 to 2.1 km ^2 and the ratio
has changed from 0.17 to 0.22.

the noise histograms are again confusing: there seem to be too many points between
-1 and +1 sigma relative to the gaussian fit.  Is something wrong with the way the
gaussians are computed?   Is there something obvious that I don't understand?

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

                        1999 November 23

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

Take a break from the dofft reductions to estimate the delay-Doppler 
dispersions in the Goldstone images.  I'm tabulating the results on the
Goldstone master log.

The July 24 image is the first that shows the obvious "gouge."  After pondering
that a bit, my best explanation is still that it's an impact crater that is not
obviously circular due to its large size relative to the size of the asteroid.
It also turns out that the concavity is somewhat visible in the July 23 image.

In retrospect, I should have used higher delay-Doppler resolution on both July 
23 and 24.  

The July 27 image is the one that shows a prominent pointed end on the LE.
I've vignetted the image, but is there actually more weak echo present?
I don't see any other, more distant points in the full array. 

July 28: This is the "twin peaks" image.  I opened the full array in Transform
and adjusted the stretch to highlight points weaker than sigma.  To my surprise,
there's a collection of points at negative frequencies that look like they've
been aliased.  They're very weak--less than 2 sigma--and they seem to trace the
LE of one of the peaks.  Perhaps this is just coincidental.  

Another issue: double check the normalization by experimenting with the 
exclusion zone used by acunorm.

July 31: there is more echo power in this image than I had noticed before. 
Specifically, the delay extent on the approaching limb is somewhat deeper and
there's clearly a large crater rotating into view.  Again, weak echo power at 
about the 1-sigma level are very common, so I need to check the normalization.
The July 31 image has changed my interpretation of the possible large "crater;"
that is, the unexplained concavity.  If one considers both the July 31 and Aug 1
images, then it appears that the concavity could be caused by a prominent ridge.
It's clear that there is echo power in the July 31 image corresponding to the dark
regions in the Aug 1 image.

What else other than a crater could the concavity be?  A topo depression among blocks
of a rubble pile...  Using the Aug 2 Arecibo image, the concavity has a visible
range extent of about 2.4 km.  If Scott's preliminary effective diameter of 3.5 km
is close to correct, then this feature is about 70% the diameter.  

The echoes on July 31 and Aug 1 were deep enough that they could have wrapped
in delay, but I don't see evidence for it in the Goldstone images (however, 
the Aug 1 Arecibo image indicates that the Aug 1 Goldstone image *should* have
wrapped--the echoes weren't strong enough to see it).

August 1: when I adjust the stretch to bring out weak points there's another
weak aliased image at negative frequencies.  Ask Steve about this... Problem
with the imaging system?  Software?  ==> Check other days to see if it's 
there.  Echoes need to be very strong to detect this.  

At any rate, the distal arc of points that is obvious in the Arecibo image on 
this day is also present in the Goldstone image.  

Presence of "ghost" images
--------------------------

Date      ghost?
----      ------
Jul 24     No
Jul 27     No
Jul 28     Yes
Jul 31     No
Aug 1      Yes
Aug 7      No
Aug 8      No

DELAY-DOPPLER DISPERSIONS
=========================

Includes pixels with echo power above the 2-sigma level.
To compute the dispersion in km or Hz, I assumed 1 pixel
is at the COM and multiplied the others by the resoution.

                                   VISIBLE
                              DELAY DISPERSION    BANDWIDTH 
DOY/Date        SETUP         (gates)    (km)   (bins)  (Hz)
--------        -----         ----------------  ------------
201/Jul 20  1.0 us x 0.1 Hz      20      2.85     19    1.8 

202/Jul 21  1.0 us x 0.1 Hz      19      2.70     17    1.6  

204/Jul 23  0.5 us x 0.075 Hz    35      2.55     20    1.43

205/Jul 24  0.5 us x 0.075 Hz    46      3.38     23    1.65

     include the distal arc ==>  58      4.28     <--same-->  

208/Jul 27  0.25 us x 0.05 Hz    88      3.26     49    2.40    

209/Jul 28  0.25 us x 0.05 Hz   105      3.90     54    2.65    

212/Jul 31  0.125 us x 0.05 Hz  185      3.45     68    3.35     

213/Aug  1  0.125 us x 0.05 Hz  223      4.16     62    3.05   

219/Aug  7  0.25 us x 0.075 Hz   72      2.66     43    3.15    

220/Aug  8  0.25 us x 0.075 Hz   89      3.30     46    3.38    

Notes:

1. For July 24, two sets of numbers are listed for the delay dispersion due to
the arc of weak points seen on that day that are seen at much higher S/N on other
days when the asteroid was in a similar orientation.  The arcuate points are all
below 2 sigma.

2. July 27: Trailing edge is difficult to define.  I didn't use contiguous 2-sigma
points in this case.  Instead, I visually integrated the TE from the receding limb
along the back and picked a plausible point as my best estimate.

3. July 28: Points on the TE are weak--many are less than 2 sigma--but they're 
contiguous so I'm counting them.  I'm using a visual estimate again of the TE
as I described above.  

4. July 31: See notes 2 and 3.  

5. Aug 1: Range extent includes weak distal arc

- - - - - - - - - - - - - - - - - - -

Return to the Goldstone CW data.

DOY 201 (July 20)
=================

reason:/data/ast5/1999JM8/proc/cw < 35 > dofft -d 5.0 -p 192 -f 512 -i VOLT99201.1999JM8 -o 99201.nocal.512.rdf -x PRDX.OUT.s17 
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99201.1999JM8
RDFOUT_1=99201.nocal.512.1_1.rdf
RDFOUT_2=99201.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99201.nocal.512.1.rdf -o 99201.nocal.512.rdf -x PRDX.OUT.s17  -p 192 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  308
Total SC spectra:  308
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 36 > 

4 hops, more than 300 looks.  Yow. 

Tsys: ch1,2 = 15.2, 16.5 K.  From before the temps should be: 
       Tsys
       ----
ch 1   15.93
ch 2   16.78

reason:/data/ast5/1999JM8/proc/cw < 38 > rdfseparate -i 99201.nocal.512.rdf -o 99201.nocal.512.sep
Dumping frame 1 to 99201.nocal.512.sep001.rdf
Dumping frame 2 to 99201.nocal.512.sep002.rdf

reason:/data/ast5/1999JM8/proc/cw < 39 > cat 99201.nocal.512.sep001.rdf 99201.nocal.512.sep002.rdf > 99201.nocal.512.corrected.rdf

Got the rnb calibrate error again:

rnb.removeBackground()  status:  Normalizing spectrum 0 with rmsc of 0.166667
rnb.Calibrate():  xmit_sta is DSS14     Default value used        
Using Observatory Gain Constant:  1.11452e+07
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
rnb.Calibrate() error:  rmsc is not what it should be (0.166667) 
                        setting rmsc to 0.09759
(  0)    1.11452e+07   83.9    19   675.569    425         4   1.95312     71.68   0.09759  0.00696483

Because irun = 1 for each look, and because I didn't change that even though
we did two runs, everything got blocked into a file.

99201.512.rdf

Rats.  I just realized that I was working with the DOY 202 file, not 201 (in tkpl, that is).
Specifically, I re-calibrated the DOY 202 file, but I set Tsys in the DOY 201 files. 

Repeat the calibration:

Still get the calibration error (as before):

rnb.Calibrate():  xmit_sta is DSS14     Default value used        
Using Observatory Gain Constant:  1.11452e+07
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
rnb.Calibrate() error:  rmsc is not what it should be (0.111803) 
                        setting rmsc to 0.0657952
(  0)    1.11452e+07  92.73  16.78   687.355    425         4   1.95312   157.696  0.0657952  0.00608281
All Finished!   :^)

I found a tkpl bug: If you have a file open and you attempt to open it again,
say, accidentally, then tkpl produces error messages if you try to use that
file.  

Polarizations are set correctly.  

308 looks.  Wow.

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2    sdev
-----------------------------------------------------------------------------------
   1    2    1    2    7   58  221    8    3    2    0    1    64.0    65.0  0.0058

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2    sdev
-----------------------------------------------------------------------------------
   1    1    1    0    2   12   38    2    0    1    0    0    64.0    65.0  0.0061

In this case, jsnr1 and 2 are set well.  The bandwidth closely matches what
I saw in the image: 1.6 Hz.  The 0.24 Hz CW echoes have a bandwidth of 2.0 Hz.
The modest difference could easily be attributable to the weakness of the 
delay-Doppler images given that we got less than two complete runs. 

If we ignore the 7 and 8 sigma points on the edges of the echo, the difference
will be at most only about 15%.  Hmm... That's more than I'd like.  
Compute the OC xsec: (0.0058)*(58+221) = 1.6 km^2.  If I include the points
on the side, the answer is 1.7 km^2.  Adopt the first estimate.

Target unknown from file /data/ast5/1999JM8/proc/cw/99201.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-oc  02:31:56  00:00:00  02:36:32   0.0   5.77e-03   1.61e+00  7.0e-03  2.9
Target unknown from file /data/ast5/1999JM8/proc/cw/99201.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-sc  02:31:56  00:00:00  02:36:32   0.0   6.08e-03   3.03e-01  7.7e-03  3.1 0.187552 0.19238 0.18273

OCxsec = 1.6 km^2, SC/OC = 0.19.  

Using the 0.244 Hz data, I got OCxsec = 2.1 km^2 and SC/OC = 0.17.  

enscript -1 -f Courier9 -r 99201.512.t87

I'm having more trouble with rdfnoisehist--it doesn't seem to be using as many 
bins as I'm specifying.  If I don't tell it how many bins to use, the SC histogram
defaults to far more bins than the OC histogram.  In either case, there seems to
be an excess of points with echo powers near zero sigma relative to the gaussian.
Conclusion: rdfnoisehist isn't reliable.  

Still to do:

Apply dofft to some of the data from the first track to get 1.95 Hz resolution.
Use either file 99199B (1000 Hz sampling, 3 runs, and four hops), or file
99199-16k (4000 Hz sampling, 4 hops, 6 runs).  99199-16k would be better because
we should get twice as many looks.  

Check the tags in the Goldstone rdf files

Verify the acunorm normalization

Verify that Mike Nolan's rdf conversion worked.  Jean-Luc's images are a mess.

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

                        1999 November 24 & 29

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

Most important rdf image file tags: year, iday, dtime, baudlen, bins, freqs, bw, fres, 
                                    incoh_sums, coh_sums, nacums

The time-related tags are the ones that concern me the most due to the power
dip that reset the clock on the VAX.  

Check the year tags on the rdf files:

reason:/data/ast5/1999JM8/proc/rng < 17 > grep "year" *.rdf
jm20108.nrm.rdf:i          year  1992 
jm20203.nrm.rdf:i          year  1992 
jm20403.nrm.rdf:i          year  1992 
jm20511.nrm.1.rdf:i          year  1992 
jm20511.nrm.rdf:i          year  1992 
jm20511.nrm1.rdf:i          year  1992 
jm20511.nrm2.rdf:i          year  1992 
jm20511.nrm3.rdf:i          year  1992 
jm20803.nrm.rdf:i          year  1992 
jm20903.nrm.rdf:i          year  1992 
jm21205.nrm.rdf:i          year  1992 
jm21305.nrm.rdf:i          year  1992 
jm21903.nrm.rdf:i          year  1992 
jm22003.nrm.rdf:i          year  1992 
jm22004.nrm.rdf:i          year  1992 
jm22005.nrm.rdf:i          year  1992 
jm22006.nrm.rdf:i          year  1992 

These are files that have already been normalized.  What about the raw files? 

Recall that the VAX crash due to the power dip reset the clock to 1992.

ranging files in /ast5/1999JM8/raw/:

DOY     year tag
---     --------
201       1999
202       1999 except for 202_rng/jm20202.rdf, which is a cold sky
204       1999
205       1999
208       1999
209       1999
212       1999
213       1999
219       1999
220       1999

DOY  iday
---  ----
201  201
202  202
204  204
205  205
208  208
209  209
212  212
213  213
219  219
220  220  

==> iday tags are fine.

file        baudlen  fres  bw    bins  freqs incoh_sums coh_sums 
----        -------  ----  ---   ----  ----- ---------- -------- 
jm20103      10     6.152 393.7  127     64      64         2    OK (not setup requested)
jm20107      11     2.237 143.2  127     64       9         5    OK
jm20108      1.0    0.100   6.4  127     64       2      1230    OK

jm20203      1.0    0.100  25.6  255    256       1       153    OK
 
jm20403      0.5    0.075  19.2  255    256       1       409    OK (log switched coh_sums/incoh_sums)
 
jm20505      10     2.461 157.5  127     64      10         5    OK
jm20508      11     2.237 143.2  127     64       9         5    OK
jm20511      0.5    0.075  19.2  255    256       1       409    OK

jm20803      0.25   0.050  12.8  255    256       1      1230    OK
 
jm20903      0.25   0.050  12.8  255    256       1      1230    OK

jm21203      0.125  0.050  12.8  255    256       1      2450    no electronic log
jm21204      0.125  0.050  12.8  255    256       1      2450    no electronic log

jm21303      0.125  0.050  12.8  255    256       1      2450    no electronic log
jm21304      0.125  0.050  12.8  255    256       1      2450    no electronic log

jm21903      0.25   0.075  19.2  255   log?

jm22003      0.25   0.075  19.2  255    256       2       817    OK
jm22004      0.25   0.075  19.2  255    256       2       817    OK
jm22005      0.25   0.075  19.2  255    256       2       817    OK
jm22006      0.25   0.075  19.2  255    256       2       817    OK

checked: all of them

 file    dtime
 ----    -----
jm20103  dtime > 86400 => subtract 86400 from each value (see below)
jm20107  dtime > 86400 => subtract 86400 from each value (see below)
jm20108  dtime > 86400 => subtract 86400 from each value (see below)

jm20203  OK 

jm20403  dtime > 86400 ==> subtract 86400 from each value (see below)

jm20505  OK 
jm20508  OK 
jm20511  OK

jm20803  dtime > 86400 ==> subtract 86400 from each value (see below)

jm20903  OK

jm21203  OK 
jm21204  OK

jm21303  OK 
jm21304  OK
  
jm21903  OK

jm22003  OK
jm22004  OK
jm22005  OK
jm22006  OK

On several days I combined multiple rdf files into one and then summed
and normalized the resulting file.  For example, jm21305.rdf.

dtime values for jm20803.rdf:

reason:/data/ast5/1999JM8/raw < 52 > grep "dtime" 208_rng/*rdf
208_rng/jm20801.rdf:d           dtime   5907.000000  
208_rng/jm20801.rdf:d           dtime   5926.000000  
208_rng/jm20801.rdf:d           dtime   5947.000000  
208_rng/jm20802.rdf:d           dtime   92673.000000  
208_rng/jm20802.rdf:d           dtime   92692.000000  
208_rng/jm20803.rdf:d           dtime   93028.000000  
208_rng/jm20803.rdf:d           dtime   93048.000000  
208_rng/jm20803.rdf:d           dtime   93160.000000  
208_rng/jm20803.rdf:d           dtime   93293.000000  
208_rng/jm20803.rdf:d           dtime   93313.000000  
208_rng/jm20803.rdf:d           dtime   93424.000000  
208_rng/jm20803.rdf:d           dtime   93550.000000  
208_rng/jm20803.rdf:d           dtime   93678.000000  
208_rng/jm20803.rdf:d           dtime   93811.000000  
208_rng/jm20803.rdf:d           dtime   93934.000000  
208_rng/jm20803.rdf:d           dtime   94066.000000  
208_rng/jm20803.rdf:d           dtime   94086.000000  
208_rng/jm20803.rdf:d           dtime   94197.000000  
208_rng/jm20803.rdf:d           dtime   94331.000000  
208_rng/jm20803.rdf:d           dtime   94464.000000  
208_rng/jm20803.rdf:d           dtime   94597.000000  
208_rng/jm20803.rdf:d           dtime   94729.000000  
208_rng/jm20803.rdf:d           dtime   94863.000000  
208_rng/jm20803.rdf:d           dtime   94996.000000  
208_rng/jm20803.rdf:d           dtime   95129.000000  
208_rng/jm20803.rdf:d           dtime   95262.000000  
208_rng/jm20803.rdf:d           dtime   95393.000000  
208_rng/jm20803.rdf:d           dtime   95521.000000  
208_rng/jm20803.rdf:d           dtime   95653.000000  
208_rng/jm20803.rdf:d           dtime   95779.000000  
208_rng/jm20803.rdf:d           dtime   95912.000000  
208_rng/jm20803.rdf:d           dtime   96040.000000  
208_rng/jm20803.rdf:d           dtime   96166.000000  
208_rng/jm20803.rdf:d           dtime   96300.000000  
208_rng/jm20803.rdf:d           dtime   96432.000000  

208_rng/jm20803.rdf:d           dtime   96564.000000  
208_rng/jm20803.rdf:d           dtime   96584.000000  
208_rng/jm20803.rdf:d           dtime   96696.000000  
208_rng/jm20803.rdf:d           dtime   96828.000000  

old value     new value
---------     ---------
93028.000000  6628
93048.000000  6648
93160.000000  6760
93293.000000  6893
93313.000000  6913
93424.000000  7024
93550.000000  7150
93678.000000  7278
93811.000000  7411
93934.000000  7534
94066.000000  7666
94086.000000  7686
94197.000000  7797
94331.000000  7931
94464.000000  8064
94597.000000  8197
94729.000000  8329
94863.000000  8463
94996.000000  8596
95129.000000  8729
95262.000000  8862
95393.000000  8993
95521.000000  9121
95653.000000  9253
95779.000000  9379
95912.000000  9512
96040.000000  9640
96166.000000  9766
96300.000000  9900
96432.000000  10032
96564.000000  10164
96584.000000  10184
96696.000000  10296
96828.000000  10428

I computed these by hand with a calculator.

reason:/data/ast5/1999JM8/raw/208_rng < 60 > grep "dtime" jm20803.rdf
d           dtime   6628.000000  
d           dtime   6648.000000  
d           dtime   6760.000000  
d           dtime   6893.000000  
d           dtime   6913.000000  
d           dtime   7024.000000  
d           dtime   7150.000000  
d           dtime   7278.000000  
d           dtime   7411.000000  
d           dtime   7534.000000  
d           dtime   7666.000000  
d           dtime   7686.000000  
d           dtime   7797.000000  
d           dtime   7931.000000  
d           dtime   8064.000000  
d           dtime   8197.000000  
d           dtime   8329.000000  
d           dtime   8463.000000  
d           dtime   8596.000000  
d           dtime   8729.000000  
d           dtime   8862.000000  
d           dtime   8993.000000  
d           dtime   9121.000000  
d           dtime   9353.000000  WRONG: 9253 --> corrected
d           dtime   9379.000000  
d           dtime   9512.000000  
d           dtime   9640.000000  
d           dtime   9766.000000  
d           dtime   9900.000000  
d           dtime   10032.000000  
d           dtime   10164.000000  
d           dtime   10184.000000  
d           dtime   10296.000000  
d           dtime   10428.000000  

jm20403.rdf: dtime values are also > 86400.  This time let's do it right: write a short
Perl script that will parse the *dtime file, subtract 86400, and then output the results.
I'll scan through the rdf file using emacs and replace the numbers by hand, and then
I'll double check them by grepping again afterward.

script: /data/ast5/1999JM8/raw/204_rng/jm8dtimeproc
   0   89613.0     3213.0
   1   89627.0     3227.0
   2   89640.0     3240.0
   3   89653.0     3253.0
   4   89776.0     3376.0
   5   89789.0     3389.0
   6   89803.0     3403.0
   7   89816.0     3416.0
   8   89933.0     3533.0
   9   89946.0     3546.0
  10   89960.0     3560.0
  11   89973.0     3573.0
  12   90097.0     3697.0
  13   90110.0     3710.0
  14   90123.0     3723.0
  15   90137.0     3737.0
  16   90357.0     3957.0
  17   90371.0     3971.0
  18   90384.0     3984.0
  19   90398.0     3998.0
  20   90520.0     4120.0
  21   90534.0     4134.0
  22   90547.0     4147.0
  23   90561.0     4161.0
  24   90681.0     4281.0
  25   90694.0     4294.0
  26   90708.0     4308.0
  27   90721.0     4321.0
  28   90842.0     4442.0
  29   90855.0     4455.0
  30   90868.0     4468.0
  31   90882.0     4482.0
  32   91006.0     4606.0
  33   91019.0     4619.0
  34   91032.0     4632.0
  35   91045.0     4645.0
  36   91163.0     4763.0
  37   91176.0     4776.0
  38   91189.0     4789.0
  39   91203.0     4803.0
  40   91320.0     4920.0
  41   91333.0     4933.0
  42   91347.0     4947.0
  43   91360.0     4960.0
  44   91483.0     5083.0
  45   91496.0     5096.0
  46   91510.0     5110.0
  47   91523.0     5123.0
  48   91646.0     5246.0
  49   91659.0     5259.0
  50   91672.0     5272.0
  51   91686.0     5286.0
  52   91807.0     5407.0
  53   91820.0     5420.0
  54   91833.0     5433.0
  55   91847.0     5447.0
  56   91969.0     5569.0
  57   91983.0     5583.0
  58   91996.0     5596.0
  59   92010.0     5610.0
  60   92128.0     5728.0
  61   92142.0     5742.0
  62   92155.0     5755.0
  63   92169.0     5769.0
  64   92287.0     5887.0
  65   92300.0     5900.0
  66   92313.0     5913.0
  67   92326.0     5926.0

I modified the original file and verified that the dtime values are 
now correct.  

I also used the Perl script to check the jm20803 dtime values that I 
computed earlier: they're OK.

DOY 201: Same problem on this day as on the DOY 205 and 208. This
includes the 10 us and 11 us coarse resolution ranging files.

Use the Perl script to fix all three files.  
jm20103: done & checked
jm20107:      "
jm20108:      "

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

                        1999 November 30 & December 1

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

dofft on the DOY 201 cw voltage data

I don't see the 16k VOLT file on /data/ast5/1999JM8/raw/199_cw/.  Perhaps it was
a very large file and I removed it?  No... I don't think that a voltage file 
exists--either there was a bug with the VME when we switched FFTs on the fly
or we forgot to tell the VME to record voltages.  (Of course, the PSD file
exists, but it doesn't offer what I want.)

Use file VOLT99199B-8k.1999JM8 instead: 3 runs, 1000 Hz sampling, four hops.  
Use a 512 point FFT to get 1.95 Hz resolution.  The resulting spectrum will have
a lot of looks and good noise statistics.

Got OSOD seek errors.  ==> I had compressed all the PRDX files.  Oops...
Try it again...  

reason:/data/ast5/1999JM8/proc/cw < 27 > dofft -d 5.0 -p 192 -f 512 -i VOLT99199B-8k.1999JM8 -o 99199B.nocal.512.rdf -x PRDX.OUT.s15
contents of ast_spec control file:
512,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199B-8k.1999JM8
RDFOUT_1=99199B.nocal.512.1_1.rdf
RDFOUT_2=99199B.nocal.512.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199B.nocal.512.1.rdf -o 99199B.nocal.512.rdf -x PRDX.OUT.s15  -p 192 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  484
Total SC spectra:  484
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 28 > 

Check the tags in tkpl:

484 looks.  

irun = 1 ==> Sum all the looks into one spectrum.

Tsys: ch1,2 = 15.2, 16.5 K.  I didn't record system temps in my electronic log for
that part of the track.  Fortunately Randy recorded them right after the track ended
and at elevation = 25 deg:  Ch1, 2 = 20.2, 21.3 K.  <== Use those values.

reason:/data/ast5/1999JM8/proc/cw < 30 > rdfseparate -i 99199B.nocal.512.rdf -o 99199B.nocal.512.sep
Dumping frame 1 to 99199B.nocal.512.sep001.rdf
Dumping frame 2 to 99199B.nocal.512.sep002.rdf
reason:/data/ast5/1999JM8/proc/cw < 31 > 

reason:/data/ast5/1999JM8/proc/cw < 31 > cat 99199B.nocal.512.sep001.rdf 99199B.nocal.512.sep002.rdf > 99199B.nocal.512.corrected.rdf
reason:/data/ast5/1999JM8/proc/cw < 32 > 

Other tags look OK.

run through the rest of the reduction pipeline.

Got another rnb.Calibrate error:

rnb.Calibrate():  xmit_sta is DSS14     Default value used        
Using Observatory Gain Constant:  1.11452e+07
(num)     Gain Const  rtt    tsys     gain   pt        nfreq     dfreq     tau       rmsc      sdev 
rnb.Calibrate() error:  rmsc is not what it should be (0.096225) 
                        setting rmsc to 0.0524864
(  0)    1.11452e+07  97.32  21.3   650.692    425         4   1.95312   247.808  0.0524864  0.00789396
All Finished!   :^)

e/m values are mostly close to unity.  Saw only a few less than 0.8 and none less than
0.6.

file: 99199B.512.rdf

Bins containing echo power and jsnr1 and 2:

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1   -0    1    0    1    3   15  130    4    2    1    0    64.0    65.0

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1    1    1    1    1    2   19   -0    1   -0    0    64.0    65.0

jsnr1 and 2 aren't set correctly.  expand to jsnr1,2 = 64, 67.

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1   -0    1    0    1    3   15  130    4    2    1    0    64.0    67.0

rows   60   61   62   63   64   65   66   67   68   69   70   jsnr1   jsnr2
---------------------------------------------------------------------------
   1    1    1    1    1    1    2   19   -0    1   -0    0    64.0    67.0

Target unknown from file /data/ast5/1999JM8/proc/cw/99199B.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-oc  07:06:05  00:00:00  07:14:08   0.0   7.49e-03   1.14e+00  8.7e-03  2.7
Target unknown from file /data/ast5/1999JM8/proc/cw/99199B.512.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-sc  07:06:05  00:00:00  07:14:08   0.0   7.89e-03   1.72e-01  8.9e-03  2.5 0.150434 0.15835 0.142535

This radar cross section is the lowest that I got on any of the days.
SC/OC is consistent with my earlier results.

plot: 99199B.512.tpl (note that the data are actually from DOY 200, not 199. 
The track crossed dates.)

- - - - - - - - - - 

Verify the normalization of the images
--------------------------------------
If the normalization is OK, it will be necessary to either fix the date and
dtime tags on many of the files or else repeat the reduction.

Nearly three months ago I printed the C source code for acunorm.c.  The comments are
rather cryptic and it isn't obvious what the exclusion zone really is.  The
question is, does the software ignore the points containing echo power to 
compute the noise statistics that are then used to scale the data?  That is the
only logical way to do it.  This boils down to: what is the exclusion zone?  Is it
an area that will be used to compute noise statistics or is it the region with the
echo that will NOT be used to compute noise statistics?  When I asked Keith 
previously (while working on Bacchus) he said it doesn't matter what l t r b are
except that they need to have some value.  He then said that they exist for targets
like Geographos that occupy a significant portion of the delay-Doppler array.  

For weak and small targets like Bacchus, it won't matter how the exclusion zone is
defined--either definition above will give results that are about the same.  It's 
different for JM8.  On several days the JM8 images occupied nearly 200 range gates
and close to 25% of the delay-Doppler array, so we need to understand what 
acunorm is doing to get the correct normalization.  

Keith's description puzzles me: "The left edge of a box of pixels to ignore
during normalization"  

Perhaps the brief description of the code explains it: "for normalizing r_images
with a specified exclusion zone"  That suggests to me that the zone is used to 
compute the noise statistics and then used to normalize the entire image.  That
agrees with what I'm starting to remember from a discussion with Keith--that
the exclusion zone shouldn't include the image.  This makes sense and it matches
the approach Mike Nolan and Jean-Luc Margot said they use.  

1. Try to figure out the code.  The fact that it's in C makes this challenging
   because C is a compact language and I'm not very familiar with it.
2. Experiment with some images and compare the results with calculations done
   by hand.  This will be more time-consuming but it should remove all doubt.

think:/data/lance/1999JM8 < 49 > acunorm -h
Usage:  acunorm [-h][-?][-g] -i infile -o outfile -l left -t top -r right -b bottom
-i infile       Specifies the RDF input  image file
-o outfile      Specifies the RDF output image file

-l left         The left edge of a box of pixels to ignore during normalization
-t top          The top edge of a box of pixels to ignore during normalization
-r right        The right edge of a box of pixels to ignore during normalization
-b bottom       The lbottom edge of a box of pixels to ignore during normalization

-g              Goldstone may deliver a bad gate 0 that disrupts normalization.
                Invoking acunorm with -g causes gate 0 to be interpolated before normalization..

-q              Invoking acunorm with -q makes it run quietly.

ftp jm21204.rdf -> think (acunorm isn't available on rhyme/reason).  Set the exclusion zone
so 
1. Echo is in the exclusion zone
2. Echo is not in exclusion zone

and compare results.

1. Echo in the exclusion zone
-----------------------------
Use the existing Spyglass Transform file to identify where the echo is.
l = 183  t = 67  r = 248  b = 245  (All counting from zero)

think:/data/lance/1999JM8/Goldstone < 65 > grep "dtime" jm21204.rdf | wc
     24      72     840
think:/data/lance/1999JM8/Goldstone < 66 > group_rdf jm21204.rdf jm21204.grp.rdf 1 24
think:/data/lance/1999JM8/Goldstone < 67 > sum_rdf jm21204.grp.rdf jm21204.sum.rdf
think:/data/lance/1999JM8/Goldstone < 68 > acunorm -i jm21204.sum.rdf -o jm21204.nrm.rdf -l 183 -t 67 -r 248 
-b 245 
Image 0  Mean 1246181874.027481  sdev 254076758.659842 count 53710
think:/data/lance/1999JM8/Goldstone < 69 > rdf2spy jm21204.nrm.rdf jm21204.nrm.spy

Doing the normalization this way puts the peak SNR = 53 in bin 215, gate 78.  
I can't compare this directly with the earlier normalization because that used
jm21203 and jm21204 combined, not just jm21204.  Get jm21205 (the combined
file) and do a direct comparison.

The peak SNR/pixel = 69.5 (file jm21205) in gate, bin = 68, 204.  
This image may have delay smear.  Return to that later.  The previous normalization
had peak SNR the same pixel but the value is 28.4.  Clearly the normalizations
are different, but which is correct?  

The total number of possible points is 255x256 = 65280.  Using l t r b above
the number being used is 53710 or about 82%.  Zone is 65 cols x 178 rows = 11570 pixels,
to the number in and out of the exclusion zone match.

Given that Keith's variable sumcount counts only the values used to compute the mean
and standard deviation, it looks like the exclusion zone bounds the echo, not the region
for the normalization.  Thus, everything BUT the exclusion zone is used to compute 
the noise statistics. 

So this is the correct answer.  This also means that the statistics in the VAX real-time
display use all the points and do not attempt to remove the echo.  So
my results for the Bacchus paper were wrong in a subtle way: the exclusion zone should
have encompassed the echo.  Fortunately those echoes were weak enough and occupied so
few pixels that it doesn't matter.  

==> Go back to all the Goldstone JM8 images and correct the normalization.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I backed up the reduction log and all other files in /data/ast5/1999JM8/analysis/,
all the *t87 files and *tpl (CW) files, the masterlog, and the electronic logs
onto think:/data/lance/1999JM8/results_backup/

This is the first JM8 backup that I've done for at least two months.

It's my intention to use think as a backup for key files on a regular basis
and to use cdroms for more general backups less often.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DELAY DRIFT ==> Not obvious.  See rotation instead
===========

** DELAY DRIFT: CHECK THE DOPPLER CORRECTIONS ON THE CW DATA TO ESTIMATE DRIFT
** SOME OF THE IMAGING TRACKS MAY BE LONG ENOUGH THAT WE'LL HAVE TO CORRECT 
** FOR THIS.  Check for it on the tracks longer than one hour.

The solution 23 tracks (DOY 209, 212, and 213) are susceptible:

DOY   delta-t (h)
---   -----------
209   1.52
212   2.51
213   3.43

These are long enough to check for delay drift in the images by summing looks
at the beginning and end and comparing the leading edges.  Then compare the results
with those expected from estimated CW COM Doppler corrections.

DOY 212
-------
I summed and normalized the first and final ten frames from each day.  There's a
not-so-subtle double image in the first ten frames.  It looks like we changed 
the txoffset in range in mid stream in the file.  This is the track when I was
flying to Puerto Rico.  The switch probably happened in the first 2-3 runs.  
==> Randy's log indicates they added a -100 gate offset after the 2nd run (2nd
record).  ==> Ignore the first two frames  

There may even be subtle rotation between the two images from the beginning 
and end of the track.  The LE may have moved up (toward the radar) by one gate.

I summed and normalized the first and last twenty frames.  The second image is
modestly stronger but otherwise any differences are so subtle that I don't see 
obvious evidence for a difference.

think:/data/lance/1999JM8/Goldstone < 101 > source jm8proc
Image 0  Mean 1235109079.945803  sdev 266915282.840177 count 53287
Image 0  Mean 1245754753.101957  sdev 270634500.282239 count 53287

There seems to be at least one gate of delay drift between these images. 
For example, the (gate,bin) = (67,204) =  1.9 in jm21205.nrm1.spy and
                                       = 28.1 in jm21205.nrm2.spy.
The echo clearly moved toward the radar by about one gate.  Could this
instead be rotation?  

There may be subtle differences in the LE on the receding limb too--to 
my eye, it looks like there's some rotation. ==> YES.  I compared points
in the same row (85) in the two images and found that the right "shoulder" is
steeper in the 2nd image. 

Perhaps the drift I mentioned before isn't drift at all but is instead 
rotation.  If the rotation about one axis is at a period of close to 8
days, then over a span of about 2 hours there should be ~4 deg of rotation.
That's consistent with what I see.  The actual time difference between
the mid-epochs of the two images is 1.8 hours.

The amount of rotation is rather modest, so to prepare images for Scott 
I'm going to provide one that's sum of all the images from this day, and 
a set of ~3 images spanning narrower intervals.  Scott can work with either format--
putting everything into one file boosts the SNR but introduces smear.  

Should we have expected delay drift?  The Doppler correction from the 0.244 Hz
res'n spectra appears to be less than 1 Hz.  If the correction had been as much
as 1 Hz, the delay drift should have been (1.8 h)*(0.42 us/h) = 0.8 us or 
about 6 1/8 us range gates.  Evidently the ephemeris on this day was very good.

Based on the slight rotation on DOY 212, we could see even more in the DOY 213 
data that covered about an hour more time.

DOY 213
-------
I was in Arecibo on this day too.  I combined files jm21303 and jm21304 -> jm21305.rdf
The first ~5 frames had range offsets that are less than the remaining frames, so
ignore the first five frames.

think:/data/lance/1999JM8/Goldstone < 105 > grep "dtime" jm21305.rdf | wc
    102     306    3570

l = 171
t = 26
r = 238
b = 225 <== Means the distal arc is not in the exclusion zone

Normalize the first and last 20 frames.

Normalizing the images on think is very slow.  

think:/data/lance/1999JM8/Goldstone < 107 > source jm8proc
Image 0  Mean 569419037.508229  sdev 124092230.611249 count 51947
Image 0  Mean 561548785.654302  sdev 122347950.927305 count 51947

There's clearly rotation: it's obvious if one selects the same row or column
in both images (in Transform) and compares the images.  For example, the apex
shifts from 27,199 -> 29,202.  The rotation is easier to see than in the DOY
212 images.  

The two images have the same number of looks but the second image is clearly
not as strong.  The power levels were consistent (we have a plot).  Perhaps 
there was some other system problem, like pointing?  Tsys?  It's hard to 
believe that such a small rotation could so obviously change the echo powers.

Delay drift?  At most the CW echo is offset by a fraction of 1 Hz, but since
the target may be somewhat asymmetric, we don't know what the drift rate 
should be.  I don't think we can pinpoint this until we do the modeling.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

PREPARE SUMMED, NORMALIZED, AND VIGNETTED IMAGES FOR SCOTT
==========================================================

DOY 213 (Aug 1)
---------------

There are 102 frames (looks) total.  Prepare one summed and properly normalized and
vignetted image from the whole track and a sequence of several images spanning
narrow time intervals.  To keep things simple, I'm going to vignette ALL the images
so to retain only positive frequencies.  Doppler frequency will increase from
right to left.  

think:/home/lance < 44 > comvin -h
Usage:  comvin infile outfile xSize Ysize xcen ycen

For example, xSize Ysize xcen ycen = 40 60 53 91 means 40 cols x 60
rows, centered on col 53, row 91.

Does comvin count from one or zero?  Do a test to find out...one

I'm doing the image processing on think: most of the rdf image software was never
converted to Solaris.  

DOY 212 (Jul 31)
----------------

There are 72 frames total, 70 at the same range offset.  Make one summed image
and a three-panel sequence.  Each panel will have ~23 frames.

Here's the script:
# Sum, normalize, and vignette all the frames with the same range offset
# The vignetting preserves 1/2 of the image at positive Doppler
# frequencies and zero Hz is on the extreme right.

group_rdf jm21205.rdf jm21205.grp.rdf 3 72
sum_rdf jm21205.grp.rdf jm21205.sum.rdf
acunorm -i jm21205.sum.rdf -o jm21205.nrm.rdf -l 182 -t 66 -r 249 -b 245
comvin jm21205.nrm.rdf jm21205.nrm.vig.rdf 128 255 193 127
rdf2spy jm21205.nrm.vig.rdf jm21205.nrm.vig.spy
rm *grp*
rm *sum*

# ----------------------------------------------------------

# Group 1
group_rdf jm21205.rdf jm21205.grp1.rdf 3 25
sum_rdf jm21205.grp1.rdf jm21205.sum1.rdf
acunorm -i jm21205.sum1.rdf -o jm21205.nrm1.rdf -l 182 -t 66 -r 249 -b 245
comvin jm21205.nrm1.rdf jm21205.nrm1.vig.rdf 128 255 193 127
rdf2spy jm21205.nrm1.vig.rdf jm21205.nrm1.vig.spy
rm *grp*
rm *sum*

# Group 2
group_rdf jm21205.rdf jm21205.grp2.rdf 26 48
sum_rdf jm21205.grp2.rdf jm21205.sum2.rdf
acunorm -i jm21205.sum2.rdf -o jm21205.nrm2.rdf -l 182 -t 66 -r 249 -b 245
comvin jm21205.nrm2.rdf jm21205.nrm2.vig.rdf 128 255 193 127
rdf2spy jm21205.nrm2.vig.rdf jm21205.nrm2.vig.spy
rm *grp*
rm *sum*

# Group 3
group_rdf jm21205.rdf jm21205.grp3.rdf 49 72
sum_rdf jm21205.grp3.rdf jm21205.sum3.rdf
acunorm -i jm21205.sum3.rdf -o jm21205.nrm3.rdf -l 182 -t 66 -r 249 -b 245
comvin jm21205.nrm3.rdf jm21205.nrm3.vig.rdf 128 255 193 127
rdf2spy jm21205.nrm3.vig.rdf jm21205.nrm3.vig.spy
rm *grp*
rm *sum*

think:/data/lance/1999JM8/Goldstone < 69 > source jm8proc
Image 0  Mean 1237806329.919117  sdev 147442627.877106 count 53287
Comvin using 193.000000,127.000000 as center
Image 0  Mean 1234995920.828420  sdev 255113546.363758 count 53287
Comvin using 193.000000,127.000000 as center
Image 0  Mean 1232369500.020943  sdev 256884778.125134 count 53287
Comvin using 193.000000,127.000000 as center
Image 0  Mean 1245709938.640794  sdev 253603645.097016 count 53287
Comvin using 193.000000,127.000000 as center

I'm putting the images for Scott into a directory labelled:
think:/data/lance/1999JM8/Goldstone/images_for_scott/

I checked all the DOY 212 and 213 Spyglass Transform files to verify
that they're OK. 

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

                        1999 December 2

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

DOY 219 (Aug 7)
---------------

This was a short track: the images span just under 45 minutes.  Group into
one image.  The first 4 looks have a different range offset relative to the
other 28, so ignore the first 4 looks.  To be really fancy I could vignette
the first four looks in such a way to align them with the others, but 
it hardly seems worth it.

think:/data/lance/1999JM8/Goldstone < 48 > source jm8proc
Image 0  Mean 585689477.274767  sdev 84628174.180943 count 59556
Comvin using 193.000000,127.000000 as center

It turns out that the previously reduced image from this day has sufficiently
low SNR that my earlier incorrect quick pass at the exclusion zone still 
produced the right peak SNR.  

Something I hadn't noticed before is the elliptical feature on the approaching 
limb.  It's about 2/3 of the way down from the LE.  It might be the crater 
that is so prominent near the top center of the images on the next day.

The DOY 220 images resemble those obtained on July 24 and August 1, so
does the DOY 219 image resemble the one obtained on DOY 212?  Well, it's
not a great match... there seems to have been some rotation about more 
than one axis.  The "shoulder" at negative freqs (relative to the COM)
crudely resembles the one in the DOY 212 images.

I tried printing the ascii array of data points using:
enscript -1 -f Courier2 -r filename.spy
but even with a fontsize of 2 I couldn't get all the columns in.  
Surprisingly, enscript did not wrap the lines, which would have 
been fine.  Later on I'll go back and run comvin to cut the 
number of columns and then print the points that include the 
echo but with more of the positive points truncated.

DOY 220 (Aug 8)
---------------

This was the longest track from which we have images: more than 7 hours.
I noticed rotation in the images while we were observing.  We got a total
of 726 looks in four files.  --> Split the images into a sequence.  SNR
has dropped relative to DOY 212 and 213 so experiment with trade-off 
between durations and SNR.

I took another look at images I reduced earlier.  Using Spyglass Transform,
I adjusted the stretch from -2.5->5 sigma to bring out weaker features.
To my surprise, the large concavity is more obvious than I thought earlier
and definitely easier to discern than on other days.  Frankly, it looks 
more like a crater on this day than on any of the others.  The rim of the
concavity seems quite angular.  Using file jm22003, the extent of the 
concavity is about 40 1/4 usec range gates or (40)(37.5 m) = 1.5 km.  This
is the largest concavity on the surface that I have been able to identify.

The "distal arc" is more of a line on this day.  Obviously it's a topographic
high... hard to say much more.

There appear to be 5 concavities in the DOY 220 images: the big one; one
near the top center-right; another elliptical in shape to the lower left;
a small one between the previous two just described; and possibly a fifth
near the LE just left of center.  The fifth resembles other craters viewed
obliquely, but it could also be a chance alignment of ridges or other 
topography.  
 
First pass: cat the final two files (5, which has only 32 looks, and 6, 
which has 180) into one file, and then sum all the looks in the resulting
three files into three images. 

That might not work: the files are too big to port to think...I need to
clear some space on think:/data/lance/.  The JM8 data takes up the most
space, but I've also got a lot from 1992 SK and 3908 Nyx.  

169 Meg total, 117 Meg of 1999JM8 files (69%).  Start by getting rid of the
mega Goldstone JM8 files from other days.  That means that I'll need to ftp them 
from reason again if I want to manipulate them.  I moved the files for Scott
over to reason and deleted the ones I've already worked with.  That 
liberated about 60 meg.  I deleted all the Arecibo rdf files (which are on 
reason) and transferred the Arecibo spy files to reason.  

Onward...

jm22003.rdf:  

This file is huge: 65 meg--processing is slow.

think:/data/lance/1999JM8/Goldstone < 168 > source jm8proc
Image 0  Mean 186499098.319827  sdev 13119291.414020 count 59232
Comvin using 193.000000,127.000000 as center

I made a new plot, applied a stretch that saturates the image at 17% 
of the maximum (71 sigma), and stretched it horizontally to search
for detail.  The big concavity looks more like a crater in this image
than in any of the others to date.  That could be an artifact of the
vertical exaggeration, or it could be real.  

What is the concavity?  The most obvious answer is that it's an impact
crater.  Or...if JM8 is a pile of loosely-bound blocks, perhaps the
concavity is the spot where several blocks join but don't fit well. 
Either situation argues for internal porosity.  If it's a crater, then,
combined with the several other ~1 km-sized craters we see, this raises
the intriguing possibility that JM8 may be a mini-Mathilde.  Steve 
finally agreed that this is an interesting and plausible possibility.

Other explanations that don't seem plausible:
1. volcanism
2. sinkhole
3. tectonic feature
4. glacial cirque
5. sea-floor spreading
6. whole-body expansion (a la a freezing icy satellite)
7. cometary outgassing?  What do those features look like?  Do we know?
   Check the literature on comet Halley--Giotto results.
8. distortion of the surface due to planetary tides
9. junction region of a bifurated object

Subdivide the image into 3 panels, each about 0.8 h long:

think:/data/lance/1999JM8/Goldstone < 182 > source jm8proc
Image 0  Mean 87289852.887831  sdev 9653231.513768 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 200897816.644381  sdev 24198046.749648 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 270299977.041599  sdev 29506246.783075 count 59232
Comvin using 193.000000,127.000000 as center

This took about 5 minutes.

jm22004.rdf

think:/data/lance/1999JM8/Goldstone < 195 > source jm8proc
Image 0  Mean 269234868.289843  sdev 16590789.443759 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 267339492.537007  sdev 28479085.528556 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 267899223.397083  sdev 28369639.702338 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 272465888.397623  sdev 29055437.890165 count 59232
Comvin using 193.000000,127.000000 as center

jm22005 & jm22006:

I catted them together to form jm22007.rdf.

think:/data/lance/1999JM8/Goldstone < 209 > source jm8proc
Image 0  Mean 297582765.505673  sdev 20478915.368859 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 278220900.941923  sdev 33123374.173496 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 295584395.263371  sdev 35262054.907755 count 59232
Comvin using 193.000000,127.000000 as center
Image 0  Mean 319248145.726364  sdev 38060094.833201 count 59232
Comvin using 193.000000,127.000000 as center

Next: the other 6 days

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I reorganized reason:/data/ast5/1999JM8/proc/cw/  I put the files from the 
most recent calibration into ../new_cw_files/ and moved all the previous
files into ../old_cw_files/  The new files have a frequency resolution of
1.95 Hz and include noise histograms (that are probably wrong due to a
bug in rdfnoisehist).  The old files include earlier calibrations that
have extensive chi-square noise statistics due to the much finer frequency
resolution.

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

                        1999 December 3  Mars Polar Lander arrives

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

DOY 209 (July 28)
-----------------
The file is jm20903.rdf.  It has 43 frames that span about 1.5 hours.  Let's prepare
one image of everything and a two-panel subset spanning 0.7-0.8 h each.

think:/data/lance/1999JM8/Goldstone < 48 > source jm8proc
Image 0  Mean 142113542.784520  sdev 21715175.634440 count 55142
Comvin using 193.000000,127.000000 as center
Image 0  Mean 142510628.089224  sdev 30289748.576637 count 55142
Comvin using 193.000000,127.000000 as center
Image 0  Mean 141697548.645896  sdev 31210486.168429 count 55142
Comvin using 193.000000,127.000000 as center

The new normalization boosted the peak SNR/pixel by more than a factor of
three.  Evidently I could have gone to 1/8 us that day.  Need to do 
correct normalizations right after the tracks to help make those decisions.

DOY 208 (July 27)
-----------------
We got only 34 looks. The images span only one hour so I'm not going to split them.

think:/data/lance/1999JM8/Goldstone < 57 > source jm8proc
Image 0  Mean 131343580.681973  sdev 22466375.001997 count 57580
Comvin using 193.000000,127.000000 as center

Peak SNR/pixel = 33, which is similar to the previous estimate. 

DOY 205 (July 24)
-----------------
We got 49 looks spanning 2.0 h.  Prepare one summed image and two spanning
about 1 hour each.  I already checked the images divided into three parts
back in July to look for rotational changes but I didn't see any.  We probably
don't have the resolution in these images.

Peak SNR/pixel is 149.  Should have used a finer baud.  We could have run
with 1/4 us or maybe even 1/8 us. 

*** 2000 JANUARY 3: THIS IS WRONG--THERE ARE 49 RUNS AND 191 FRAMES.
*** MOST OF THE DATA HASN'T BEEN INCLUDED.  See the entry for 2000 January 3

DOY 204 (July 23)
-----------------
There are 68 frames that span only 0.75 hours: make one image.

The first 16 frames used no range offset; the other frames used
an offset of +25 usec.  16/68 = 24% of the total, which is not
insignificant.  Let's vignette the first 16 frames so as to align
them with the others and then sum them.  

We need to move the center point by 25 usec or 50 gates (0.5 us/gate).

Try this on the first 16 frames to see if comvin will work correctly.
I modified comvin as follows:

#comvin jm20403.nrm.rdf jm20403.nrm.vig.rdf 128 255 193 127
comvin jm20403.nrm.rdf jm20403.nrm.vig.rdf 128 255 193 77

That put the LE in gate 33 (counting from zero).  Fortunately, Keith's comvin
software is smart enough to wrap in range and Doppler.  That matches the LE
in the other frames, so full speed ahead.

Here's the script:

group_rdf jm20403.rdf jm20403.grp1.rdf 1 16
comvin jm20403.grp1.rdf jm20403.grp1.shift.rdf 256 255 193 77
group_rdf jm20403.rdf jm20403.grp2.rdf 17 68
cat jm20403.grp1.shift.rdf jm20403.grp2.rdf > jm20403.grp.rdf
sum_rdf jm20403.grp.rdf jm20403.sum.rdf
acunorm -i jm20403.sum.rdf -o jm20403.nrm.rdf -l 166 -t 29 -r 205 -b 79
comvin jm20403.nrm.rdf jm20403.nrm.vig.rdf 128 255 193 127
rdf2spy jm20403.nrm.vig.rdf jm20403.nrm.vig.spy
rm *grp*
rm *sum*

This worked: the images are registered.

Peak SNR = 61 vs. 52 with the normalization I did in July.

==> Onward.  

How good was the ephemeris on this day?  The 0.244 Hz cw spectrum
has its center at about +0.2 Hz and the bandwidth is about 2.4 Hz.
Given that we don't know the shape, that small offset is too low to
be an issue.

DOY 202 (July 21)
-----------------
There are 112 frames, 14 of which have no range offset.  I'm going to 
reduce those first to see how strong they are and then decide whether
or not to register them with the others.

I should have been more aggressive and gone with finer resolution.  These
echoes are strong--we probably could have run with 0.25 us.  

Yow!  There's a lot of echo power!  ==> register with the other images.
The track was only about 45 minutes long -> one image.

I forgot that we inserted a Doppler offset too--try it again.
No, the Doppler offset of +5 Hz was the same.  This is another ghost
image, probably caused by problems with i and q.  There's quite a bit 
of echo power in the ghost image--some of the points exceed 20 sigma.
This is by far the strongest ghost image I've seen in the data.  We didn't
notice this during the track because we zoomed in the real-time display
to see the echo.  The ghost echo isn't strong enough to have a significant
effect (i.e. more than several sigma) on the normalization so I'm 
going to ignore it.

The images span only 45 minutes->1 image.

The peak SNR is about 180.  There are several other points with echo
strengths in excess of 100 sigma.  I wish I had gone with at least 0.5 usec;
0.25 usec would have been even better.  This is frustrating.  Next time...

DOY 201 (July 20)
-----------------

9 frames, SNR is low enough that a new normalization isn't really needed, 
but let's do it anyway to get things right and to have consistency in the
vignetting of all the rdf files for Scott.

This is the only day that I used a 127-element code.  

Here's the script:

# jm20108: sum into one file

group_rdf jm20108.rdf jm20108.grp.rdf 1 9
sum_rdf jm20108.grp.rdf jm20108.sum.rdf
acunorm -i jm20108.sum.rdf -o jm20108.nrm.rdf -l 40 -t 35 -r 63 -b 89
comvin jm20108.nrm.rdf jm20108.nrm.vig.rdf 32 127 49 63
#rdf2spy jm20108.nrm.rdf jm20108.nrm.spy
rdf2spy jm20108.nrm.vig.rdf jm20108.nrm.vig.spy
rm *grp*
rm *sum*

think:/data/lance/1999JM8/Goldstone < 84 > source jm8proc                         
Image 0  Mean 94086779.130410  sdev 23086656.889027 count 6886
Comvin using 49.000000,63.000000 as center

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

                        1999 December 6 

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

I'm finally back to working on the Arecibo images of JM8.  I realized that
we have only one copy of the Caltech Baseband Recorder (CBR) data, so I
copied everything from the cdrom Mike Nolan sent onto rhyme and tried to 
burn more CDs.  I managed to burn one, but one of the OC files on the first
day (Aug 1) seems to be corrupted.  None of the other three cds that I burned
were readable by the cdrom drives in either rhyme or reason.  Steve contacted
Richard Zinar about getting a new cd rom burner.  So right now we have 
1 cd from Nolan, 1 of our own that may be corrupted, and all the files on 
rhyme:/cdmaster/cdroot2/   I'm going to leave the files on /cdmaster for a 
while because there isn't enough space on /data/ast5/ to load all of them.
Right now there is a separate file for OC and SC from each run.

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

                        1999 December 13 

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

Disk space is an issue:

/dev/dsk/c0t2d0s1    2118718 1013448  893400    54%    /data/ast1
/dev/dsk/c0t2d0s3    2118718 1570295  336553    83%    /data/ast2
rhyme:/cdmaster      1968608 1393312  378432    79%    /cdmaster
rhyme:/data/ast3     2077232 1613848  255664    87%    /data/ast3
rhyme:/data/ast4     2077232 1490952  378560    80%    /data/ast4
rhyme:/data/ast5     2077232 1696536  172976    91%    /data/ast5
rhyme:/data/ast6     2082712 1449488  424952    78%    /data/ast6

Recall that the CBR data is on /cdmaster/cdroot2/.  Le't put all
the CBR data onto /ast1 and then link it to /data/ast5/arecibo/
and then clear the files off of /cdmaster/cdroot2/...Except that I 
don't have write permission on /ast1.  Sent Steve email asking him
to change the write permission.  ==> Steve cleared some space on 
/ast6, but it's still not enough.  We can get rid of 1999 FN19, which 
has been backed up multiple times.  Actually, let's toss the 1999 FN19
voltage files and leave everything else alone--that will release
about 180 meg on top of the ~400 M Steve already made available. 

Here's the available space:
rhyme:/data/ast6     2082712 1249520  624920    67%    /data/ast6

I put all the files into: /data/ast6/1999JM8_arecibo/ and created links
in /data/ast5/1999JM8/raw/.

Meanwhile, let's forge ahead by checking tags on the DOY 216 (Aug 4) 
files.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

CHECK CBR DATA TAGS
===================

DOY 216 (Aug 4)
---------------
Here are the files:

reason:/data/ast5/1999JM8/arecibo/raw/216_rng_cbr < 52 > ls run*
run19990804132600.rdf      run19990804133032.rdf      run19990804133504.rdf
run19990804132600.sc.rdf   run19990804133032.sc.rdf   run19990804133504.sc.rdf
run19990804132816.rdf      run19990804133248.rdf
run19990804132816.sc.rdf   run19990804133248.sc.rdf

Example of the tags from the first OC file (run19990804132600.rdf):

Header:

c       Type      Float
i       Height    800 # Number of range rows in image
i       Width     300 # Number of Doppler columns in image
i       Size      4
c       Machine   SPARC
c       Format    RDF_Image
.

Tail:

c       DATA_TYPE PWR
i       freqs     18308 # Transform length
i       CHANS     1
i       FRAMES    1
i       bins      65535 # Before vignetting
i       IDAY 216 # Day Of Year (UTC)
d       DTIME 48360 # Receive start time (UTC seconds)
i       CODE_LEN 65535
f       BW 152.590218966964 # Of original unvignetted image (Hz)
f       FRES 0.00833461978189667 # (Hz)
f       BAUDLEN 0.1 # in microseconds
f       INT_TIME 60 # Total receive time (seconds)
i       YEAR 1999
f       EPH_ROW 401.33 # row in which ephemeris range lies.
f       EPH_COL 199.90739 # column in which ephemeris Doppler lies
#       0.0 is the center of the first pixel for above.
f       LOOPTIME 10.1 # Closed-loop time included in EPH_ROW
c       EPHEMERIS /share/olda/Ephm/1999jm8.PRDX.OUT.s23
.

reason:/data/ast5/1999JM8/arecibo/raw/216_rng_cbr < 55 > cat Readme.1999aug04 
1999 aug 04 1999 JM8

These files were take from CBR data 2-bit sampled at 10 MHz.  The files
ending in sc are the same-sense data, the unlabeled ones are
opposite-sense.  The data were decoded (using an idl procedure and fftw
2.2.1).  The .lags files contain the decoded data containing lags
29700-30499 (zero-based).  The images are full-run ffts, zero-filled
once.  fft frequencies 400-699 were kept (zero-based), out of
9154 *2=18308=.00833461978189666908 Hz/px

The "unvig" files kept frequencies -1000-999, to show the sign.

runs were 60 s long

images were scaled to sigmas using range bins 0..49 to compute mean and sigma.

Mike Nolan vignetted the image from the original 65535-code array.

Verify that there are 800 rows x 300 columns using rdf2spy on think: YES
The echo powers are rather strange: it's common to see ~50 sigma pixels
adjacent to much weaker pixels.  Perhaps this is a consequence of zero-
extension?  The units of the pixels are apparently sigmas.  YES, even though
his tag says they're powers.

(10 MHz)*(65535) = 0.006554
1/0.006554 = 152.59 Hz (1 accumulation)
152.59/18308 DFT = 0.008335 Hz/bin ==> CORRECT

grep on the tags to verify the values.  Compute dtime, eph_col, eph_row below.

TAG       expect   get
---       ------   ---
height     800     800 
width      300     300 
freqs    18308   18308
bins     65535   65535
iday       216     216
code_len 65535   65535
bw       152.59  152.59
fres     0.0083  0.0083
baudlen  0.1     0.1
int_time 60      60
year     1999    1999
eph_row  401.33  variable--was it drifting?  Wrong?  See below.  
eph_col  199.91  199.91 
looptime 10.1    10.1
ephemeris 23     23

Others to check: dtime.  Double check eph_row, eph_col, and freqs
Mike zero-extended the files once and then applied a discrete 
Fourier Transform.  

EPH_ROW:

reason:/cdmaster/cdroot2/1999aug04 < 82 > grep "EPH_ROW " *rdf                             
run19990804132600.rdf:f       EPH_ROW 401.33 # row in which ephemeris range lies.
run19990804132600.sc.rdf:f       EPH_ROW 401.33 # row in which ephemeris range lies.
run19990804132816.rdf:f       EPH_ROW 400.53 # row in which ephemeris range lies.
run19990804132816.sc.rdf:f       EPH_ROW 400.53 # row in which ephemeris range lies.
run19990804133032.rdf:f       EPH_ROW 401.21 # row in which ephemeris range lies.
run19990804133032.sc.rdf:f       EPH_ROW 401.21 # row in which ephemeris range lies.
run19990804133248.rdf:f       EPH_ROW 401.14 # row in which ephemeris range lies.
run19990804133248.sc.rdf:f       EPH_ROW 401.14 # row in which ephemeris range lies.
run19990804133504.rdf:f       EPH_ROW 401.12 # row in which ephemeris range lies.
run19990804133504.sc.rdf:f       EPH_ROW 401.12 # row in which ephemeris range lies.

What's going on?  Did Mike try to correct for delay drift?  

EPH_ROW is variable on the other days too--something related to when we turned on
the CBR?  Tape destriping?  Something wrong with the decoding?  CLT?  Mike's 
comment indicates that the CLT was involved...  My memory of this is vague: ASK Mike.
Clearly the time it takes to get the signal from the platform down to the 
control room is part of it...  Something about the way that eph_delay is
computed...  Mike and Phil were working on this.  

In any case, eph_row refers to the vignetted file, not the original array.

EPH_COL

What was the offset?  We did transmit Dopplers due to the CBR.  
Nolan retained zero based bins 400-699; the ephemeris column (bin) is 199.91,
or 599.91 relative to zero.  (599.91)*(0.008335 Hz/bin) = +5.0 Hz, which 
is reasonable.  Unfortunately, nobody recorded the offset in the notes
for this setup.

DTIME

run19990804132600.rdf:d       DTIME 48360 # Receive start time (UTC seconds)
run19990804132600.sc.rdf:d       DTIME 48360 # Receive start time (UTC seconds)
run19990804132816.rdf:d       DTIME 48496 # Receive start time (UTC seconds)
run19990804132816.sc.rdf:d       DTIME 48496 # Receive start time (UTC seconds)
run19990804133032.rdf:d       DTIME 48632 # Receive start time (UTC seconds)
run19990804133032.sc.rdf:d       DTIME 48632 # Receive start time (UTC seconds)
run19990804133248.rdf:d       DTIME 48768 # Receive start time (UTC seconds)
run19990804133248.sc.rdf:d       DTIME 48768 # Receive start time (UTC seconds)
run19990804133504.rdf:d       DTIME 48904 # Receive start time (UTC seconds)
run19990804133504.sc.rdf:d       DTIME 48904 # Receive start time (UTC seconds)

dtime   time     OK?
48360  13:26:00  yes:  Mike already converted this to UTC!  
48496  13:28:16  yes
48632  133032    yes
48768  133248    yes
48904  133504    yes

==> dtime values are OK.

Fourier Transform length
------------------------
I don't understand how to determine how much to pad the data or
how to determine what the transform length will be.  For this day
a 16 k transform would have given comparable results in terms of
frequency resolution.   

OK--Here's what Mike did: the RTT was 60 seconds.  We want to match
one look/run, so nlooks = int_time/(1/fres) = 1
What's fres?  fres = bw/fft = 1/60 sec = 0.0167 Hz.  With a 60 second
RTT that's the finest frequency resolution we could get without 
zero-extending and it would require using an FFT that is NOT in the 
form of 2^N.  Since the bandwidth = 152.59 Hz = fres*FFT, 
FFT would be 9154 as Mike mentions.

Using an 8192 FFT, which IS in the form 2^N, the finest
frequency resolution that the unextended data can provide is 0.019 Hz.  

So what Mike did was to zero extend the data once--that is, to double the 
effective integration time by padding the data with zeros, and then he FFTed 
the modified file.  That doubled the FFT length from 9154->18308 as advertised.

According to Numerical Recipes, FFTs need to be divisible by two 
into integers but they do not need to be in the form of 2^N, although
that format makes computation MUCH faster.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 213 (Aug 1)
===============

reason:/data/ast5/1999JM8/arecibo/raw/213_rng_cbr < 253 > cat Readme.1999aug01 
1999 aug 01 1999 JM8

These files were take from CBR data 2-bit sampled at 10 MHz.  The files
ending in sc are the same-sense data, the unlabeled ones are
opposite-sense.  The data were decoded (using an idl procedure and fftw
2.2.1).  The .lags files contain the decoded data containing lags
28500-30499 (zero-based).  The images are full-run ffts, zero-filled
once.  fft frequencies -150,149 were kept (zero-based), out of
7780*2=15560=0.009806569 Hz/px

There was no transmit offset on this day, and the frequencies are reversed
from other days (didn't use the PDC, and used a low-side LO on the 260-30)

runs were 51 s long

images were scaled to sigmas using range bins 0..49 to compute mean and sigma.

The CBR was restarted in the middle, so there are two sets of data.

So no offset in freq ==> eph_col should = 150 using the *vignetted* file.

There are 35 runs.

PDC = Planetary Down Converter
260-30 = 260 - 30 MHz mixer

TAG       expect   get
---       ------   ---
height    2000    2000
width      300     300
freqs    15560   15560
bins     65535   65535
iday       213     213   
code_len 65535   65535
bw       152.59  152.59
fres     0.0098  0.0098
baudlen  0.1     0.1
int_time 51      51
year     1999    1999
eph_row  variable
eph_col  150       150  (See below)
looptime 10.1    10.1
ephemeris 21     21

dtime

Mike's comment indicates these are in UTC:
                                               UTC
run19990801125104.sc.rdf:d       DTIME 46264 12:51:04 
run19990801125302.sc.rdf:d       DTIME 46382 12 53 02
run19990801125500.sc.rdf:d       DTIME 46500 12 55 00
run19990801125658.sc.rdf:d       DTIME 46618 12 56 58
run19990801125856.sc.rdf:d       DTIME 46736 12 58 56
run19990801130054.sc.rdf:d       DTIME 46854 13 00 54
run19990801130252.sc.rdf:d       DTIME 46972 13 02 52
run19990801130450.sc.rdf:d       DTIME 47090 13 04 50
run19990801130648.sc.rdf:d       DTIME 47208 13 06 48
run19990801130846.sc.rdf:d       DTIME 47326 13 08 46
run19990801131044.sc.rdf:d       DTIME 47444 13 10 44

...gap of four runs...

run19990801132601.sc.rdf:d       DTIME 48361 13 26 01
run19990801132759.sc.rdf:d       DTIME 48479 13 27 59
run19990801132957.sc.rdf:d       DTIME 48597 13 29 57
run19990801133155.sc.rdf:d       DTIME 48715 13 31 55
run19990801133353.sc.rdf:d       DTIME 48833 13 33 53
run19990801133551.sc.rdf:d       DTIME 48951 13 35 51
run19990801133749.sc.rdf:d       DTIME 49069 13 37 49
run19990801133947.sc.rdf:d       DTIME 49187 13 39 47
run19990801134145.sc.rdf:d       DTIME 49305 13 41 45
run19990801134343.sc.rdf:d       DTIME 49423 13 43 43
run19990801134541.sc.rdf:d       DTIME 49541 13 45 41
run19990801134739.sc.rdf:d       DTIME 49659 13 47 39
run19990801134937.sc.rdf:d       DTIME 49777 13 49 37
run19990801135135.sc.rdf:d       DTIME 49895 13 51 35
run19990801135333.sc.rdf:d       DTIME 50013 13 53 33

The dtime values all check out OK.

eph_row
-------

These values bounce around somewhat but otherwise steadily increase from
1533->1548.  Let's ask Mike.  This got a lot better later in the week--there
was much less variation.  Registering these images will be a pain.

eph_col
-------

Mike counted eph_col from zero using the *vignetted* image, not from the
unvignetted original.  

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

                        1999 December 14 

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

DOY 214 (AUG 2)
===============

reason:/data/ast5/1999JM8/arecibo/raw/214_rng_cbr < 18 > cat Readme.1999aug02 
1999 aug 02 1999 JM8

These files were take from CBR data 2-bit sampled at 10 MHz.  The files
ending in sc are the same-sense data, the unlabeled ones are
opposite-sense.  The data were decoded (using an idl procedure and fftw
2.2.1).  The .lags files contain the decoded data containing lags
29500-30999 (zero-based).  The images are full-run ffts, zero-filled
once.  fft frequencies -650,-351 were kept (zero-based), out of
8086*2=16172=0.009435458 Hz/px

The "unvig" files kept frequencies -1000-999, to show the sign.

runs were 53 s long

images were scaled to sigmas using range bins 0..49 to compute mean and sigma.

TAG       expect   get
---       ------   ---
Height    1500    1500
Width      300     300
freqs    16172   16172  
bins     65535   65535
IDAY       214     214     
CODE_LEN 65535   65535
BW       152.59   152.59
FRES     0.0094  0.0094
BAUDLEN  0.1      0.1
INT_TIME 53       53
YEAR     1999    1999
EPH_ROW    variable  
EPH_COL  178.92     178.92  See below.
LOOPTIME 10.1     10.1
EPHEMERIS 23      23      

FFT
===

8086*2 = 16172 checks out.  (1/53)/2 = 0.0094 which matches Mike's result.

EPH_ROW
=======

This is variable again and it increases as a function of time.  I hope
the situation in the GSB data is better.

EPH_COL
=======

Mike retained bins -650 -> -351.  i.e., 300 Doppler bins.
The center relative to the unvignetted file is -500.

So the center bin of the *vignetted* file is 150, but that's not the 
ephemeris Doppler: Mike states it's 178.92.  Shouldn't it be 150?

Evidently there was a tx offset... (78 bins)*(0.0094 Hz/bin) = 0.74 Hz?  
The log sheet says the offset was +5 Hz.  The setup file also indicates +5 Hz. 
What's going on?  

I would expect:  (+5 Hz)/(0.0094 Hz/bin) = +529.9 bins. 

OK...Now I understand.  With the +5 Hz offset and counting from zero, not one,
that would put the ephemeris col at 29 bins relative to original bin -500 or
+29 relative to bin 150 in the vigentted file.  

The echo is clearly offset to the right in the image--so bin 179 seems to
be near the middle, although not dead-on.  

DTIME
=====
                                               UTC
run19990802130204.sc.rdf:d       DTIME 46924 13:02:04
run19990802130406.sc.rdf:d       DTIME 47046 13 04 06
run19990802130608.sc.rdf:d       DTIME 47168 13 06 08
run19990802130810.sc.rdf:d       DTIME 47290 13 08 10
run19990802131012.sc.rdf:d       DTIME 47412 13 10 12
run19990802131214.sc.rdf:d       DTIME 47534 13 12 14
run19990802131416.sc.rdf:d       DTIME 47656 13 14 16
run19990802131618.sc.rdf:d       DTIME 47778 13 16 18
run19990802131820.sc.rdf:d       DTIME 47900 13 18 20
run19990802132022.sc.rdf:d       DTIME 48022 13 20 22
run19990802132224.sc.rdf:d       DTIME 48144 13 22 24
run19990802132426.sc.rdf:d       DTIME 48266 13 24 26
run19990802132628.sc.rdf:d       DTIME 48388 13 26 28
run19990802132830.sc.rdf:d       DTIME 48510 13 28 30
run19990802133032.sc.rdf:d       DTIME 48632 13 30 32
run19990802133234.sc.rdf:d       DTIME 48754 13 32 34
run19990802133436.sc.rdf:d       DTIME 48876 13 34 36
run19990802133638.sc.rdf:d       DTIME 48998 13 36 38
run19990802133840.sc.rdf:d       DTIME 49120 13 38 40 
run19990802134042.sc.rdf:d       DTIME 49242 13 40 42
run19990802134244.sc.rdf:d       DTIME 49364 13 42 44
run19990802134446.sc.rdf:d       DTIME 49486 13 44 46
run19990802134648.sc.rdf:d       DTIME 49608 13 46 48
run19990802134850.sc.rdf:d       DTIME 49730 13 48 50
run19990802135052.sc.rdf:d       DTIME 49852 13 50 52
run19990802135254.sc.rdf:d       DTIME 49974 13 52 54
run19990802135456.sc.rdf:d       DTIME 50096 13 54 56
run19990802135658.sc.rdf:d       DTIME 50218 13 56 58

These values are all correct.

The first file has not been normalized!
Check a few others...I checked three more, scattered throughout
the total number of files.  They aren't normalized.
==> No big deal--just use acunorm.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 214 (Aug 3)
===============

reason:/data/ast6/1999JM8_arecibo/1999aug03 < 15 > cat Readme.1999aug03
1999 aug 03 1999 JM8

These files were take from CBR data 2-bit sampled at 10 MHz.  The files
ending in sc are the same-sense data, the unlabeled ones are
opposite-sense.  The data were decoded (using an idl procedure and fftw
2.2.1).  The .lags files contain the decoded data containing lags
29700-30499 (zero-based).  The images are full-run ffts, zero-filled
once.  fft frequencies 400-699 were kept (zero-based), out of
8544 *2=17090=0.008929671 Hz/px

The "unvig" files kept frequencies -1000-999, to show the sign.

runs were 56 s long

images were scaled to sigmas using range bins 0..49 to compute mean and sigma.

==> THE IMAGES ARE *NOT* NORMALIZED! <==

TAG       expect   get
---       ------   ---
Height     800     800
Width      300     300
freqs    17090   17090
bins     65535   65535
IDAY       215     215 
CODE_LEN 65535   65535
BW       152.59   152.59
FRES     0.0089  0.0089
BAUDLEN  0.1       0.1
INT_TIME 56       56
YEAR     1999    1999
EPH_ROW    variable  
EPH_COL   160.0  160.0  
LOOPTIME 10.1     10.1
EPHEMERIS 23      23

fres looks OK.

EPH_ROW
=======

This varies by less than two range gates.  Much better than on 
Aug 1 and 2.  

EPH_COL
=======

The setup file indicates we used a +5 Hz txoffset.  So the center
freq in the unvignetted file should be:
#bins = (+5 Hz)/(0.008930 Hz/bin) = 560 bins

Mike retained bins 400-699 (zero-based), so the midpoint is
(400 + 699)/2 = 549.5 or about 550.  So the eph col should be
at about +10 bins relative to that.  In the vignetted frame, 
expect eph_col at about 160.  ==> That's where it is.

DTIME
=====
                                                UTC
run19990803124312.sc.rdf:d       DTIME 45792 12:43:12
run19990803124520.sc.rdf:d       DTIME 45920 12 45 20
run19990803124728.sc.rdf:d       DTIME 46048 12 47 28
run19990803124936.sc.rdf:d       DTIME 46176 12 49 36
run19990803125144.sc.rdf:d       DTIME 46304 12 51 44
run19990803125352.sc.rdf:d       DTIME 46432 12 53 52
run19990803125600.sc.rdf:d       DTIME 46560 12 56 00
run19990803125808.sc.rdf:d       DTIME 46688 12 58 08
run19990803130016.sc.rdf:d       DTIME 46816 13 00 16
run19990803130224.sc.rdf:d       DTIME 46944 13 02 24
run19990803130432.sc.rdf:d       DTIME 47072 13 04 32
run19990803130640.sc.rdf:d       DTIME 47200 13 06 40
run19990803130848.sc.rdf:d       DTIME 47328 13 08 48
run19990803131056.sc.rdf:d       DTIME 47456 13 10 56
run19990803131304.sc.rdf:d       DTIME 47584 13 13 04
run19990803131512.sc.rdf:d       DTIME 47712 13 15 12
run19990803131720.sc.rdf:d       DTIME 47840 13 17 20
run19990803131928.sc.rdf:d       DTIME 47968 13 19 28
run19990803132136.sc.rdf:d       DTIME 48096 13 21 36
run19990803132344.sc.rdf:d       DTIME 48224 13 23 44
run19990803132552.sc.rdf:d       DTIME 48352 13 25 52
run19990803132800.sc.rdf:d       DTIME 48480 13 28 00
run19990803133008.sc.rdf:d       DTIME 48608 13 30 08
run19990803133216.sc.rdf:d       DTIME 48736 13 32 16
run19990803133424.sc.rdf:d       DTIME 48864 13 34 24
run19990803133632.sc.rdf:d       DTIME 48992 13 36 32
run19990803133840.sc.rdf:d       DTIME 49120 13 38 40
run19990803134048.sc.rdf:d       DTIME 49248 13 40 48
run19990803134256.sc.rdf:d       DTIME 49376 13 42 56
run19990803134504.sc.rdf:d       DTIME 49504 13 45 04
run19990803134900.sc.rdf:d       DTIME 49740 13 49 00

dtime values are OK.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 217 (Aug 5)
===============

reason:/data/ast6/1999JM8_arecibo/1999aug05 < 65 > cat Readme.1999aug05
1999 aug 05 1999 JM8

These files were take from CBR data 2-bit sampled at 10 MHz.  The files
ending in sc are the same-sense data, the unlabeled ones are
opposite-sense.  The data were decoded (using an idl procedure and fftw
2.2.1).  The .lags files contain the decoded data containing lags
29700-30499 (zero-based).  The images are full-run ffts, zero-filled
once.  fft frequencies 500-799 were kept (zero-based), out of
9764*2=19528=.007813919 Hz/bin.

The "unvig" files kept frequencies -1000 -999, to show the sign.

runs were 64s long.

THESE IMAGES ARE NOT NORMALIZED

TAG       expect   get
---       ------   ---
Height     800    800 
Width      300    300
freqs    19528  19528
bins     65535   65535
IDAY       217   217
CODE_LEN 65535   65535
BW       152.59  152.59
FRES     0.0078 0.0078  
BAUDLEN  0.1     0.1
INT_TIME 64      64      
YEAR     1999    1999
EPH_ROW    VARIABLE: see below      
EPH_COL  139.88  139.88 
LOOPTIME 10.1   10.1
EPHEMERIS 26     26

FRES
====

1/(64*2) = 0.00781 Hz/bin which agrees with what Mike got.

EPH_ROW
=======

The value again varies within a few tenths of a gate around row 401.
We won't have to worry about registering the looks in these data.

EPH_COL
=======

There are 300 bins: 500-799 (zero based).  The logfile (which is
included as part of the setup file) indicates that TXoff = +5 Hz.
#bins = (+5 Hz)/(0.007814 Hz/bin) = 639.9 bins in the unvignetted
file.

640-500 = 140 = eph_col in the vignetted file--matches Mike's result. 

DTIME
=====
                                               UTC
run19990805115814.sc.rdf:d       DTIME 43094 11:58:14
run19990805120038.sc.rdf:d       DTIME 43238 12 00 38
run19990805120302.sc.rdf:d       DTIME 43382 12 03 02
run19990805120526.sc.rdf:d       DTIME 43526 12 05 26
run19990805120750.sc.rdf:d       DTIME 43670 12 07 50
run19990805121014.sc.rdf:d       DTIME 43814 12 10 14
run19990805121238.sc.rdf:d       DTIME 43958 12 12 38
run19990805121502.sc.rdf:d       DTIME 44102 12 15 02
run19990805121726.sc.rdf:d       DTIME 44246 12 17 26
run19990805121950.sc.rdf:d       DTIME 44390 12 19 50
run19990805122214.sc.rdf:d       DTIME 44534 12 22 14
run19990805122438.sc.rdf:d       DTIME 44678 12 24 38
run19990805122702.sc.rdf:d       DTIME 44822 12 27 02
run19990805122926.sc.rdf:d       DTIME 44966 12 29 26
run19990805123150.sc.rdf:d       DTIME 45110 12 31 50
run19990805123414.sc.rdf:d       DTIME 45254 12 34 14
run19990805123638.sc.rdf:d       DTIME 45398 12 36 38
run19990805123902.sc.rdf:d       DTIME 45542 12 39 02
run19990805124126.sc.rdf:d       DTIME 45686 12 41 26
run19990805124350.sc.rdf:d       DTIME 45830 12 43 50
run19990805124614.sc.rdf:d       DTIME 45974 12 46 14
run19990805124838.sc.rdf:d       DTIME 46118 12 48 38
run19990805125102.sc.rdf:d       DTIME 46262 12 51 02
run19990805125326.sc.rdf:d       DTIME 46406 12 53 26
run19990805125550.sc.rdf:d       DTIME 46550 12 55 50
run19990805125814.sc.rdf:d       DTIME 46694 12 58 14
run19990805130038.sc.rdf:d       DTIME 46838 13 00 38
run19990805130302.sc.rdf:d       DTIME 46982 13 03 02
run19990805130526.sc.rdf:d       DTIME 47126 13 05 26
run19990805130750.sc.rdf:d       DTIME 47270 13 07 50
run19990805131014.sc.rdf:d       DTIME 47414 13 10 14
run19990805131238.sc.rdf:d       DTIME 47558 13 12 38
run19990805131502.sc.rdf:d       DTIME 47702 13 15 02
run19990805131726.sc.rdf:d       DTIME 47846 13 17 26
run19990805131950.sc.rdf:d       DTIME 47990 13 19 50

dtime values are OK.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 218 (Aug 6)
===============

reason:/data/ast6/1999JM8_arecibo/1999aug06 < 80 > cat Readme.1999aug06
1999 aug 06 1999 JM8

These files were take from CBR data 2-bit sampled at 10 MHz.  The files
ending in sc are the same-sense data, the unlabeled ones are
opposite-sense.  The data were decoded (using an idl procedure and fftw
2.2.1).  The .lags files contain the decoded data containing lags
29700-30499 (zero-based).  The images are full-run ffts, zero-filled
once.  fft frequencies 500-899 were kept (zero-based), out of
10375 *2=20750=0.007353745 Hz/px

The "unvig" files kept frequencies -1000-999, to show the sign.

runs were 68 s long

images were scaled to sigmas using range bins 0..49 to compute mean and sigma.

THESE IMAGES ARE NOT NORMALIZED

TAG       expect   get
---       ------   ---
Height     800     800
Width      400     400
freqs    20750   20750
bins     65535   65535
IDAY       218     218
CODE_LEN 65535   65535
BW       152.59  152.59
FRES     0.0074  0.0074
BAUDLEN  0.1     0.1
INT_TIME 68       68
YEAR     1999    1999
EPH_ROW    VARIABLE: see below      
EPH_COL  180     180   
LOOPTIME 10.1   10.1
EPHEMERIS 26    26

FRES
====

(1/[68*2]) = 0.00735 Hz which is what Mike used.

EPH_ROW
=======

EPH_ROW varies by about +/- 0.3 gates. 

EPH_COL
=======

Mike kept freqs 500-899 (zero based).

The logfile indicates that we used txoff = +5 Hz.

#bins = (5 Hz)/(0.00735) = 680.3 bins which is eph_col in
the unvignetted file.  
 
In the vignetted file, eph_col = 680.3 - 500 = 180.3
Mike got 180, so they're consistent.

DTIME
=====
                                               UTC
run19990806123350.sc.rdf:d       DTIME 45230 12:33:50
run19990806123622.sc.rdf:d       DTIME 45382 12 36 22
run19990806123854.sc.rdf:d       DTIME 45534 12 38 54
run19990806124126.sc.rdf:d       DTIME 45686 12 41 26
run19990806124358.sc.rdf:d       DTIME 45838 12 43 58
run19990806124630.sc.rdf:d       DTIME 45990 12 46 30
run19990806124902.sc.rdf:d       DTIME 46142 12 49 02
run19990806125134.sc.rdf:d       DTIME 46294 12 51 34
run19990806125406.sc.rdf:d       DTIME 46446 12 54 06
run19990806125638.sc.rdf:d       DTIME 46598 12 56 38
run19990806125910.sc.rdf:d       DTIME 46750 12 59 10
run19990806130142.sc.rdf:d       DTIME 46902 13 01 42
run19990806130414.sc.rdf:d       DTIME 47054 13 04 14
run19990806130646.sc.rdf:d       DTIME 47206 13 06 46

The last file doesn't have any data--the asteroid was out of the beam.
I deleted that file from /data/ast6/1999JM8_arecibo/1999aug06/

reason:/data/ast6/1999JM8_arecibo/1999aug06 < 86 > rm run*130646*
rm: run19990806130646.rdf: override protection 444 (yes/no)? yes
rm: run19990806130646.sc.rdf: override protection 444 (yes/no)? yes

Note: I used the SC files out of convenience with the display.

Duh... I just realized that the filenames Mike used include rcsta.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DOY 221 (Aug 9)
===============
reason:/data/ast6/1999JM8_arecibo/1999aug09 < 106 > cat Readme.1999aug09 
1999 aug 09 1999 JM8

These files were take from CBR data 2-bit sampled at 10 MHz.  The files
ending in sc are the same-sense data, the unlabeled ones are
opposite-sense.  The data were decoded (using an idl procedure and fftw
2.2.1).  The .lags files contain the decoded data containing lags
29700-30499 (zero-based).  The images are full-run ffts, zero-filled
once.  fft frequencies 600-999 were kept (zero-based), out of
12664*2=25328=.00602456644689530233 Hz/bin.  The last run was longer:
fft length 12816*2=25632 = .00595311403585222446 Hz/bin

The "unvig" files kept frequencies -1000-999, to show the sign.

runs were 83s long, except for the last one 84s

THESE DATA ARE NOT NORMALIZED

There are 26 good runs, 25 with the same frequency resolution.  
Due to the difference in resolution, let's ignore the last run.

reason:/data/ast6/1999JM8_arecibo/1999aug09 < 125 > rm *120226*
rm: run19990809120226.rdf: override protection 444 (yes/no)? yes
rm: run19990809120226.sc.rdf: override protection 444 (yes/no)? yes

TAG       expect   get
---       ------   ---
Height     800    800
Width      400    400
freqs    25328   25328 
bins     65535   65535
IDAY       221    221
CODE_LEN 65535   65535
BW       152.59  152.59
FRES     0.0060  0.0060
BAUDLEN  0.1     0.1
INT_TIME 83      83
YEAR     1999    1999
EPH_ROW  401      401
EPH_COL  230      230
LOOPTIME 10.1    10.1
EPHEMERIS 26     26

FRES
====

1/[83*2] = 0.0060 Hz

EPH_COL
=======

Mike retained 600-999.  txoff = +5 Hz, so 
#bins = (5 Hz)/(0.0060246 Hz/bin) = 830 bins in the unvignetted
image.  In the vignetted image eph_col should = 830-600 = 230
which agrees with what Mike got.

EPH_ROW
=======

eph_row varies by +/- about 0.3 gates, centered on #401 (counting
from zero).

DTIME
=====
                   
run19990809104635.sc.rdf:d       DTIME 38795 10:46:35
run19990809104937.sc.rdf:d       DTIME 38977 10 49 37
run19990809105239.sc.rdf:d       DTIME 39159 10 52 39
run19990809105541.sc.rdf:d       DTIME 39341 10 55 41
run19990809105843.sc.rdf:d       DTIME 39523 10 58 43
run19990809110145.sc.rdf:d       DTIME 39705 11 01 45
run19990809110447.sc.rdf:d       DTIME 39887 11 04 47
run19990809110749.sc.rdf:d       DTIME 40069 11 07 49
run19990809111051.sc.rdf:d       DTIME 40251 11 10 51
run19990809111353.sc.rdf:d       DTIME 40433 11 13 53
run19990809111655.sc.rdf:d       DTIME 40615 11 16 55
run19990809111957.sc.rdf:d       DTIME 40797 11 19 57
run19990809112259.sc.rdf:d       DTIME 40979 11 22 59
run19990809112601.sc.rdf:d       DTIME 41161 11 26 01
run19990809112903.sc.rdf:d       DTIME 41343 11 29 03
run19990809113205.sc.rdf:d       DTIME 41525 11 32 05
run19990809113507.sc.rdf:d       DTIME 41707 11 35 07
run19990809113809.sc.rdf:d       DTIME 41889 11 38 09
run19990809114111.sc.rdf:d       DTIME 42071 11 41 11
run19990809114413.sc.rdf:d       DTIME 42253 11 44 13
run19990809114715.sc.rdf:d       DTIME 42435 11 47 15
run19990809115017.sc.rdf:d       DTIME 42617 11 50 17
run19990809115319.sc.rdf:d       DTIME 42799 11 53 19
run19990809115621.sc.rdf:d       DTIME 42981 11 56 21
run19990809115923.sc.rdf:d       DTIME 43163 11 59 23

These values are all OK.

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

GROUP THE CBR FILES INTO ONE FILE/DAY AND NORMALIZE THEM
--------------------------------------------------------

The key point here is eph_row: it varied by up to 10 gates on 
some days, but less than one gate at the end of the eperiment.

      eph_row
DOY  variation
---  ---------
213  1533-1548
214  579-611   Registration will be a nuisance
215  +/- 0.5
216      0.4
217      0.5
218      0.3
221      0.3

The final five days are easy: just cat, sum, and normalize.  The
first two days will require more work.

Here are eph_row for DOY 213 and 214:

1999aug01/run19990801125104.sc.rdf:f       EPH_ROW 1533.12 # row in which ephemeris range lies.
1999aug01/run19990801125302.sc.rdf:f       EPH_ROW 1533.99 # row in which ephemeris range lies.
1999aug01/run19990801125500.sc.rdf:f       EPH_ROW 1533.99 # row in which ephemeris range lies.
1999aug01/run19990801125658.sc.rdf:f       EPH_ROW 1533.6 # row in which ephemeris range lies.
1999aug01/run19990801125856.sc.rdf:f       EPH_ROW 1535.35 # row in which ephemeris range lies.
1999aug01/run19990801130054.sc.rdf:f       EPH_ROW 1535.31 # row in which ephemeris range lies.
1999aug01/run19990801130252.sc.rdf:f       EPH_ROW 1534.57 # row in which ephemeris range lies.
1999aug01/run19990801130450.sc.rdf:f       EPH_ROW 1535.98 # row in which ephemeris range lies.
1999aug01/run19990801130648.sc.rdf:f       EPH_ROW 1535.62 # row in which ephemeris range lies.
1999aug01/run19990801130846.sc.rdf:f       EPH_ROW 1535.51 # row in which ephemeris range lies.
1999aug01/run19990801131044.sc.rdf:f       EPH_ROW 1536.62 # row in which ephemeris range lies.
1999aug01/run19990801132601.sc.rdf:f       EPH_ROW 1540.65 # row in which ephemeris range lies.
1999aug01/run19990801132759.sc.rdf:f       EPH_ROW 1542.37 # row in which ephemeris range lies.
1999aug01/run19990801132957.sc.rdf:f       EPH_ROW 1542.32 # row in which ephemeris range lies.
1999aug01/run19990801133155.sc.rdf:f       EPH_ROW 1543.44 # row in which ephemeris range lies.
1999aug01/run19990801133353.sc.rdf:f       EPH_ROW 1541.58 # row in which ephemeris range lies.
1999aug01/run19990801133551.sc.rdf:f       EPH_ROW 1542.84 # row in which ephemeris range lies.
1999aug01/run19990801133749.sc.rdf:f       EPH_ROW 1544.08 # row in which ephemeris range lies.
1999aug01/run19990801133947.sc.rdf:f       EPH_ROW 1545.37 # row in which ephemeris range lies.
1999aug01/run19990801134145.sc.rdf:f       EPH_ROW 1543.57 # row in which ephemeris range lies.
1999aug01/run19990801134343.sc.rdf:f       EPH_ROW 1544.73 # row in which ephemeris range lies.
1999aug01/run19990801134541.sc.rdf:f       EPH_ROW 1544.79 # row in which ephemeris range lies.
1999aug01/run19990801134739.sc.rdf:f       EPH_ROW 1545.71 # row in which ephemeris range lies.
1999aug01/run19990801134937.sc.rdf:f       EPH_ROW 1547.46 # row in which ephemeris range lies.
1999aug01/run19990801135135.sc.rdf:f       EPH_ROW 1547.02 # row in which ephemeris range lies.
1999aug01/run19990801135333.sc.rdf:f       EPH_ROW 1548.3 # row in which ephemeris range lies.

1999aug02/run19990802130204.sc.rdf:f       EPH_ROW 578.87 # row in which ephemeris range lies.
1999aug02/run19990802130406.sc.rdf:f       EPH_ROW 580.21 # row in which ephemeris range lies.
1999aug02/run19990802130608.sc.rdf:f       EPH_ROW 581.16 # row in which ephemeris range lies.
1999aug02/run19990802130810.sc.rdf:f       EPH_ROW 581.86 # row in which ephemeris range lies.
1999aug02/run19990802131012.sc.rdf:f       EPH_ROW 584.18 # row in which ephemeris range lies.
1999aug02/run19990802131214.sc.rdf:f       EPH_ROW 585.14 # row in which ephemeris range lies.
1999aug02/run19990802131416.sc.rdf:f       EPH_ROW 584.63 # row in which ephemeris range lies.
1999aug02/run19990802131618.sc.rdf:f       EPH_ROW 585.73 # row in which ephemeris range lies.
1999aug02/run19990802131820.sc.rdf:f       EPH_ROW 588.35 # row in which ephemeris range lies.
1999aug02/run19990802132022.sc.rdf:f       EPH_ROW 589.44 # row in which ephemeris range lies.
1999aug02/run19990802132224.sc.rdf:f       EPH_ROW 590.01 # row in which ephemeris range lies.
1999aug02/run19990802132426.sc.rdf:f       EPH_ROW 591.01 # row in which ephemeris range lies.
1999aug02/run19990802132628.sc.rdf:f       EPH_ROW 593.35 # row in which ephemeris range lies.
1999aug02/run19990802132830.sc.rdf:f       EPH_ROW 594.07 # row in which ephemeris range lies.
1999aug02/run19990802133032.sc.rdf:f       EPH_ROW 595.09 # row in which ephemeris range lies.
1999aug02/run19990802133234.sc.rdf:f       EPH_ROW 596.31 # row in which ephemeris range lies.
1999aug02/run19990802133436.sc.rdf:f       EPH_ROW 596.73 # row in which ephemeris range lies.
1999aug02/run19990802133638.sc.rdf:f       EPH_ROW 598.3 # row in which ephemeris range lies.
1999aug02/run19990802133840.sc.rdf:f       EPH_ROW 598.96 # row in which ephemeris range lies.
1999aug02/run19990802134042.sc.rdf:f       EPH_ROW 599.65 # row in which ephemeris range lies.
1999aug02/run19990802134244.sc.rdf:f       EPH_ROW 602.31 # row in which ephemeris range lies.
1999aug02/run19990802134446.sc.rdf:f       EPH_ROW 603.9 # row in which ephemeris range lies.
1999aug02/run19990802134648.sc.rdf:f       EPH_ROW 605.33 # row in which ephemeris range lies.
1999aug02/run19990802134850.sc.rdf:f       EPH_ROW 607.48 # row in which ephemeris range lies.
1999aug02/run19990802135052.sc.rdf:f       EPH_ROW 608.4 # row in which ephemeris range lies.
1999aug02/run19990802135254.sc.rdf:f       EPH_ROW 608.98 # row in which ephemeris range lies.
1999aug02/run19990802135456.sc.rdf:f       EPH_ROW 610.06 # row in which ephemeris range lies.
1999aug02/run19990802135658.sc.rdf:f       EPH_ROW 610.71 # row in which ephemeris range lies.

GROUP THE IMAGES INTO ONE FILE/DAY
==================================

Start with the easiest day with the fewest runs: Aug 4

DOY 216 (Aug 4)
---------------

5 runs, each 952 k = 4.8 Meg.

reason:/data/ast6/1999JM8_arecibo/1999aug04 < 26 > du -ks *rdf
952     run19990804132600.rdf
952     run19990804132600.sc.rdf
952     run19990804132816.rdf
952     run19990804132816.sc.rdf
952     run19990804133032.rdf
952     run19990804133032.sc.rdf
952     run19990804133248.rdf
952     run19990804133248.sc.rdf
952     run19990804133504.rdf
952     run19990804133504.sc.rdf

cat run19990804132600.rdf run19990804133248.rdf run19990804133032.rdf run19990804132816.rdf run19990804133504.rdf > jm8.cbr.990804.rdf

cat run19990804132600.sc.rdf run19990804133248.sc.rdf run19990804133032.sc.rdf run19990804132816.sc.rdf run19990804133504.sc.rdf > jm8.cbr.990804.sc.rdf

Now delete the individual files to recover space...done

DOY 218 (Aug 6)
---------------

OC:
cat run19990806123350.rdf run19990806123622.rdf run19990806123854.rdf run19990806124126.rdf run19990806124358.rdf run19990806124630.rdf run19990806124902.rdf run19990806125134.rdf run19990806125406.rdf run19990806125638.rdf run19990806125910.rdf run19990806130142.rdf run19990806130414.rdf > jm8.990806.cbr.rdf

SC:
cat run19990806123350.sc.rdf run19990806123622.sc.rdf run19990806123854.sc.rdf run19990806124126.sc.rdf run19990806124358.sc.rdf run19990806124630.sc.rdf run19990806124902.sc.rdf run19990806125134.sc.rdf run19990806125406.sc.rdf run19990806125638.sc.rdf run19990806125910.sc.rdf run19990806130142.sc.rdf run19990806130414.sc.rdf > jm8.990806.cbr.sc.rdf

All my xterm windows vanished when I deleted the run*rdf files... ??

DOY 221 (Aug 9)
---------------

OC
cat run19990809104635.rdf run19990809104937.rdf run19990809105239.rdf run19990809105541.rdf run19990809105843.rdf run19990809110145.rdf run19990809110447.rdf run19990809110749.rdf run19990809111051.rdf run19990809111353.rdf run19990809111655.rdf run19990809111957.rdf run19990809112259.rdf run19990809112601.rdf run19990809112903.rdf run19990809113205.rdf run19990809113507.rdf run19990809113809.rdf run19990809114111.rdf run19990809114413.rdf run19990809114715.rdf run19990809115017.rdf run19990809115319.rdf run19990809115621.rdf run19990809115923.rdf > jm8.990809.cbr.rdf

SC
cat run19990809104635.sc.rdf run19990809104937.sc.rdf run19990809105239.sc.rdf run19990809105541.sc.rdf run19990809105843.sc.rdf run19990809110145.sc.rdf run19990809110447.sc.rdf run19990809110749.sc.rdf run19990809111051.sc.rdf run19990809111353.sc.rdf run19990809111655.sc.rdf run19990809111957.sc.rdf run19990809112259.sc.rdf run19990809112601.sc.rdf run19990809112903.sc.rdf run19990809113205.sc.rdf run19990809113507.sc.rdf run19990809113809.sc.rdf run19990809114111.sc.rdf run19990809114413.sc.rdf run19990809114715.sc.rdf run19990809115017.sc.rdf run19990809115319.sc.rdf run19990809115621.sc.rdf run19990809115923.sc.rdf > jm8.990809.cbr.sc.rdf

DOY 213 (Aug 01)
----------------

OC
cat run19990801125104.rdf run19990801130846.rdf run19990801133947.rdf run19990801125302.rdf run19990801131044.rdf run19990801134145.rdf run19990801125500.rdf run19990801132601.rdf run19990801134343.rdf run19990801125658.rdf run19990801132759.rdf run19990801134541.rdf run19990801125856.rdf run19990801132957.rdf run19990801134739.rdf run19990801130054.rdf run19990801133155.rdf run19990801134937.rdf run19990801130252.rdf run19990801133353.rdf run19990801135135.rdf run19990801130450.rdf run19990801133551.rdf run19990801135333.rdf run19990801130648.rdf run19990801133749.rdf > jm8.990801.cbr.rdf

SC
cat run19990801125104.sc.rdf   run19990801130846.sc.rdf   run19990801133947.sc.rdf run19990801125302.sc.rdf   run19990801131044.sc.rdf   run19990801134145.sc.rdf run19990801125500.sc.rdf   run19990801132601.sc.rdf   run19990801134343.sc.rdf run19990801125658.sc.rdf   run19990801132759.sc.rdf   run19990801134541.sc.rdf run19990801125856.sc.rdf   run19990801132957.sc.rdf   run19990801134739.sc.rdf run19990801130054.sc.rdf   run19990801133155.sc.rdf   run19990801134937.sc.rdf run19990801130252.sc.rdf   run19990801133353.sc.rdf   run19990801135135.sc.rdf run19990801130450.sc.rdf   run19990801133551.sc.rdf   run19990801135333.sc.rdf run19990801130648.sc.rdf   run19990801133749.sc.rdf > jm8.990801.cbr.sc.rdf

DOY 214 (Aug 02)
----------------

OC
cat run19990802130204.rdf      run19990802133032.rdf run19990802130406.rdf      run19990802133234.rdf run19990802130608.rdf      run19990802133436.rdf run19990802130810.rdf      run19990802133638.rdf run19990802131012.rdf      run19990802133840.rdf run19990802131214.rdf      run19990802134042.rdf run19990802131416.rdf      run19990802134244.rdf run19990802131618.rdf      run19990802134446.rdf run19990802131820.rdf      run19990802134648.rdf run19990802132022.rdf      run19990802134850.rdf run19990802132224.rdf      run19990802135052.rdf run19990802132426.rdf      run19990802135254.rdf run19990802132628.rdf      run19990802135456.rdf run19990802132830.rdf      run19990802135658.rdf > jm8.990802.cbr.rdf

SC
cat run19990802130204.sc.rdf   run19990802133032.sc.rdf run19990802130406.sc.rdf   run19990802133234.sc.rdf run19990802130608.sc.rdf   run19990802133436.sc.rdf run19990802130810.sc.rdf   run19990802133638.sc.rdf run19990802131012.sc.rdf   run19990802133840.sc.rdf run19990802131214.sc.rdf   run19990802134042.sc.rdf run19990802131416.sc.rdf   run19990802134244.sc.rdf run19990802131618.sc.rdf   run19990802134446.sc.rdf run19990802131820.sc.rdf   run19990802134648.sc.rdf run19990802132022.sc.rdf   run19990802134850.sc.rdf run19990802132224.sc.rdf   run19990802135052.sc.rdf run19990802132426.sc.rdf   run19990802135254.sc.rdf run19990802132628.sc.rdf   run19990802135456.sc.rdf run19990802132830.sc.rdf   run19990802135658.sc.rdf > jm8.990802.cbr.sc.rdf

I screwed this up: I accidentally deleted the *sc.rdf files before I had catted them
all.  Get the others off the CDrom.

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

                        1999 December 15 

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

I recopied the original rdf files from the cdrom and catted everything together.

Richard Zinar is updating software on think to make it y2k compliant so I may need
to use intruder to sum and normalize the images.  

DOY 215 (Aug 03)
----------------

OC
cat run19990803124312.rdf run19990803124520.rdf run19990803124728.rdf run19990803124936.rdf run19990803125144.rdf run19990803125352.rdf run19990803125600.rdf run19990803125808.rdf run19990803130016.rdf run19990803130224.rdf run19990803130432.rdf run19990803130640.rdf run19990803130848.rdf run19990803131056.rdf run19990803131304.rdf run19990803131512.rdf run19990803131720.rdf run19990803131928.rdf run19990803132136.rdf run19990803132344.rdf run19990803132552.rdf run19990803132800.rdf run19990803133008.rdf run19990803133216.rdf run19990803133424.rdf run19990803133632.rdf run19990803133840.rdf run19990803134048.rdf run19990803134256.rdf run19990803134504.rdf run19990803134900.rdf > jm8.990803.cbr.rdf

SC
cat run19990803124312.sc.rdf run19990803124520.sc.rdf run19990803124728.sc.rdf run19990803124936.sc.rdf run19990803125144.sc.rdf run19990803125352.sc.rdf run19990803125600.sc.rdf run19990803125808.sc.rdf run19990803130016.sc.rdf run19990803130224.sc.rdf run19990803130432.sc.rdf run19990803130640.sc.rdf run19990803130848.sc.rdf run19990803131056.sc.rdf run19990803131304.sc.rdf run19990803131512.sc.rdf run19990803131720.sc.rdf run19990803131928.sc.rdf run19990803132136.sc.rdf run19990803132344.sc.rdf run19990803132552.sc.rdf run19990803132800.sc.rdf run19990803133008.sc.rdf run19990803133216.sc.rdf run19990803133424.sc.rdf run19990803133632.sc.rdf run19990803133840.sc.rdf run19990803134048.sc.rdf run19990803134256.sc.rdf run19990803134504.sc.rdf run19990803134900.sc.rdf > jm8.990803.cbr.sc.rdf

DOY 217 (Aug 05)
----------------

OC
cat run19990805115814.rdf run19990805120038.rdf run19990805120302.rdf run19990805120526.rdf run19990805120750.rdf run19990805121014.rdf run19990805121238.rdf run19990805121502.rdf run19990805121726.rdf run19990805121950.rdf run19990805122214.rdf run19990805122438.rdf run19990805122702.rdf run19990805122926.rdf run19990805123150.rdf run19990805123414.rdf run19990805123638.rdf run19990805123902.rdf run19990805124126.rdf run19990805124350.rdf run19990805124614.rdf run19990805124838.rdf run19990805125102.rdf run19990805125326.rdf run19990805125550.rdf run19990805125814.rdf run19990805130038.rdf run19990805130302.rdf run19990805130526.rdf run19990805130750.rdf run19990805131014.rdf run19990805131238.rdf run19990805131502.rdf run19990805131726.rdf run19990805131950.rdf > jm8.990805.cbr.rdf

SC
cat run19990805115814.sc.rdf run19990805120038.sc.rdf run19990805120302.sc.rdf run19990805120526.sc.rdf run19990805120750.sc.rdf run19990805121014.sc.rdf run19990805121238.sc.rdf run19990805121502.sc.rdf run19990805121726.sc.rdf run19990805121950.sc.rdf run19990805122214.sc.rdf run19990805122438.sc.rdf run19990805122702.sc.rdf run19990805122926.sc.rdf run19990805123150.sc.rdf run19990805123414.sc.rdf run19990805123638.sc.rdf run19990805123902.sc.rdf run19990805124126.sc.rdf run19990805124350.sc.rdf run19990805124614.sc.rdf run19990805124838.sc.rdf run19990805125102.sc.rdf run19990805125326.sc.rdf run19990805125550.sc.rdf run19990805125814.sc.rdf run19990805130038.sc.rdf run19990805130302.sc.rdf run19990805130526.sc.rdf run19990805130750.sc.rdf run19990805131014.sc.rdf run19990805131238.sc.rdf run19990805131502.sc.rdf run19990805131726.sc.rdf run19990805131950.sc.rdf > jm8.990805.cbr.sc.rdf

15:04--I entered "ls" and my xterm vanished again.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Richard Zinar forgot to check on the size of think's system hard drive and 
discovered, after he'd wiped the old system, that the new one wouldn't fit:
the drive is too small.  So that means we probably won't have access to think
or create until Richard gets a new, larger drive tomorrow morning.  Why
didn't he think to check that before he wiped the drive?  He even mentioned 
that he'd encountered this problem before (although several years ago). 

Thus, in order to do any rdf image processing, I need to use intruder, which
uses old versions of some of the software.   What a pain.

All this came about because Richard is installing a somewhat newer system
4.4.x onto think in order to make it Y2k compliant.  When I asked him what
might fail if we didn't do the patch he couldn't answer.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Let's do the processing on intruder:/export/data0/rosema/1999JM8/proc

Start with Aug 4 first because that's the file on that date is the
smallest: it's only 4.7 Meg.

Be sure to check the year tag on the normalized files.  

Also need to use rdf2spy to locate where the echo is in each image 
in order to set the boundary of the exclusion zone.  

Unfortunately, my master script is on think too...but fortunately I copied 
part of it into my log above.

# reason:/data/ast5/1999JM8/arecibo/proc/rng/jm8.ao.proc
#
# Lance A. M. Benner
# Created: 1999 December 15
# Modified:1999 December 15
#
# This script is designed to be run on intruder.gdscc.nasa.gov, which
# has an older version of acunorm than the one available on 
# think.jpl.nasa.gov.

# Sum, normalize, and vignette all the frames with the same range offset

# 1999 Aug 04 (DOY 216)

group_rdf jm8.cbr.990804.rdf jm8.cbr.990804.grp.rdf 1 5
sum_rdf jm8.cbr.990804.grp.rdf jm8.cbr.990804.sum.rdf
acunorm jm8.cbr.990804.sum.rdf jm8.cbr.990804.nrm.rdf 182 66 249 245
rdf2spy jm8.cbr.990804.nrm.rdf jm8.cbr.990804.nrm.spy
#rm *grp*
#rm *sum*

I'm editing this on reason and then ftping it to intruder.

lance@intruder:/tmp_mnt/home/lance [17] source jm8.ao.proc
Image 0  Mean 0.262777  sdev 1.892277 count 228007

Recall that image registration is no problem from DOY 215 onward.  It's 
a drag on DOY 213 and 214 because eph_row varied.

I ftped the *spy file back to JPL, displayed it to set l t r b,
and then repeated the reduction with the corrrect exclusion zone.

Here's the modified script:

# 1999 Aug 04 (DOY 216)

# Sum, normalize, and vignette all the frames with the same range offset
# l t r b = 127 268 265 619 define a rectangle that encloses the echo

group_rdf jm8.cbr.990804.rdf jm8.cbr.990804.grp.rdf 1 5
sum_rdf jm8.cbr.990804.grp.rdf jm8.cbr.990804.sum.rdf
acunorm jm8.cbr.990804.sum.rdf jm8.cbr.990804.nrm.rdf 127 268 265 619
rdf2spy jm8.cbr.990804.nrm.rdf jm8.cbr.990804.nrm.spy
rm *grp*
rm *sum*

lance@intruder:/tmp_mnt/home/lance [24] source jm8.ao.proc
Image 0  Mean -0.000953  sdev 0.445475 count 191562

Put these files in: reason:/data/ast5/1999JM8/arecibo/proc/rng/images_for_scott/

Setting the exclusion zone properly boosted the max SNR/pxl by
about a factor of 5.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 215 (Aug 03)
----------------

This file has 31 looks and it's large: 30 Meg.  It's taking a long time
to ftp to intruder.  This is going to take a long time to normalize too.

Here's the script:

# 1999 Aug 03 (DOY 215)

# Sum, normalize, and vignette all the frames with the same range offset
# l t r b = 83 267 204 602 define a rectangle that encloses the echo

group_rdf jm8.990803.cbr.rdf jm8.990803.cbr.grp.rdf 1 31
sum_rdf jm8.990803.cbr.grp.rdf jm8.990803.cbr.sum.rdf
acunorm jm8.990803.cbr.sum.rdf jm8.990803.cbr.nrm.rdf 83 267 204 602
rdf2spy jm8.990803.cbr.nrm.rdf jm8.990803.cbr.nrm.spy
rm *grp*
rm *sum*

lance@intruder:/tmp_mnt/home/lance [13] source jm8.ao.proc
Image 0  Mean 4128162991.929171  sdev 742742338.457548 count 199465

Actually, normalization took only a couple of minutes.  

The peak SNR/pixel exceeds 1000!

Image appears to be slightly smeared--possibly due to the 
eph_row problem--recall that it varied by +/- 0.5 gates on this day.
There may be some subtle rotational smear too.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 217 (Aug 05)
----------------

file: jm8.990805.cbr.rdf

reason:/data/ast6/1999JM8_arecibo/1999aug05 < 5 > grep "DTIME " *sc.rdf | wc
      35     315    1925

# 1999 Aug 05 (DOY 217)

# Sum, normalize, and vignette all the frames with the same range offset
# l t r b = 83 267 204 602 define a rectangle that encloses the echo

group_rdf jm8.990805.cbr.rdf jm8.990805.cbr.grp.rdf 1 35
sum_rdf jm8.990805.cbr.grp.rdf jm8.990805.cbr.sum.rdf
acunorm jm8.990805.cbr.sum.rdf jm8.990805.cbr.nrm.rdf 62 201 208 562
rdf2spy jm8.990805.cbr.nrm.rdf jm8.990805.cbr.nrm.spy
rm *grp*
rm *sum*

lance@intruder:/tmp_mnt/home/lance [22] source jm8.ao.proc
Image 0  Mean 4716134380.761113  sdev 796180194.267568 count 187294

This is the really nice image that "looks like an asteroid."  It's
one of the four included in the press release.  The craters are much
more obvious than in the press release image--we'll be able to count
them better than I expected.  There's a hint of range smear again.

The peak SNR/pixel is about 670.  Wow.  In retrospect, Mike Nolan 
was right to zero-extend once.  

This image requires using a logarithmic stretch to view 

THE DOPPLER SENSE IS THE REVERSE OF JEAN-LUC'S IMAGES

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 218 (Aug 06)
----------------

There are 13 looks.  

#group_rdf jm8.990806.cbr.rdf jm8.990806.cbr.grp.rdf 1 13
#sum_rdf jm8.990806.cbr.grp.rdf jm8.990806.cbr.sum.rdf
#acunorm jm8.990806.cbr.sum.rdf jm8.990806.cbr.nrm.rdf 93 130 241 559
#rdf2spy jm8.990806.cbr.nrm.rdf jm8.990806.cbr.nrm.spy
#rm *grp*
#rm *sum*

lance@intruder:/tmp_mnt/home/lance [33] source jm8.ao.proc
Image 0  Mean 6322496629.808723  sdev 1754605261.528195 count 256508

Peak SNR/pixel is about 210.  See many craters--should be able to 
match them with craters seen on other days.  Not as many as on Aug 5,
though.  We have only about 1/3 the number of looks and the target
was farther away--not as much detail, despite the marginally higher
freq resn.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 221 (Aug 09)
----------------

There are 25 looks. 

# 1999 Aug 09 (DOY 221)

# Sum, normalize, and vignette all the frames with the same range offset
# l t r b = 83 267 204 602 define a rectangle that encloses the echo

group_rdf jm8.990809.cbr.rdf jm8.990809.cbr.grp.rdf 1 25
sum_rdf jm8.990809.cbr.grp.rdf jm8.990809.cbr.sum.rdf
acunorm jm8.990809.cbr.sum.rdf jm8.990809.cbr.nrm.rdf 132 196 315 571
rdf2spy jm8.990809.cbr.nrm.rdf jm8.990809.cbr.nrm.spy
rm *grp*
rm *sum*

This image has more detail than the one from the Golevka box.
The prominent concavity just below the LE looks like a crater
that has had its sides truncated by subsequent impacts.  There
appears to be a topographic high near the center of the concavity--
but I doubt it's a central peak--I don't think we'd get those with 
such small craters on such a small object.  More likely it's something
on the "other" hemisphere that is superimposed.  NEAT!

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

                        1999 December 16 & 17

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

DOY 213 (Aug 01)
----------------
Due to the drift in eph_row, summing this image will require a bit of 
effort.  In effect, this is the same as removing delay drift, as I did
with the Bacchus images.  

reason:/data/ast6/1999JM8_arecibo/1999aug01 < 23 > grep "EPH_ROW " *sc.rdf
f       EPH_ROW 1533.12 # row in which ephemeris range lies.
f       EPH_ROW 1535.51 # row in which ephemeris range lies.
f       EPH_ROW 1545.37 # row in which ephemeris range lies.
f       EPH_ROW 1533.99 # row in which ephemeris range lies.
f       EPH_ROW 1536.62 # row in which ephemeris range lies.
f       EPH_ROW 1543.57 # row in which ephemeris range lies.
f       EPH_ROW 1533.99 # row in which ephemeris range lies.
f       EPH_ROW 1540.65 # row in which ephemeris range lies.
f       EPH_ROW 1544.73 # row in which ephemeris range lies.
f       EPH_ROW 1533.6 # row in which ephemeris range lies.
f       EPH_ROW 1542.37 # row in which ephemeris range lies.
f       EPH_ROW 1544.79 # row in which ephemeris range lies.
f       EPH_ROW 1535.35 # row in which ephemeris range lies.
f       EPH_ROW 1542.32 # row in which ephemeris range lies.
f       EPH_ROW 1545.71 # row in which ephemeris range lies.
f       EPH_ROW 1535.31 # row in which ephemeris range lies.
f       EPH_ROW 1543.44 # row in which ephemeris range lies.
f       EPH_ROW 1547.46 # row in which ephemeris range lies.
f       EPH_ROW 1534.57 # row in which ephemeris range lies.
f       EPH_ROW 1541.58 # row in which ephemeris range lies.
f       EPH_ROW 1547.02 # row in which ephemeris range lies.
f       EPH_ROW 1535.98 # row in which ephemeris range lies.
f       EPH_ROW 1542.84 # row in which ephemeris range lies.
f       EPH_ROW 1548.3 # row in which ephemeris range lies.
f       EPH_ROW 1535.62 # row in which ephemeris range lies.
f       EPH_ROW 1544.08 # row in which ephemeris range lies.

The mean is 1540.30 and the maximum excursions are + 8 and -7.2 gates
Use comvin to center the echoes at some value and then add a tag 
to the data file indicating what I did.  

Use the mean value of 1540 as the standard.  Note that we can shift
only in increments of whole gates, so adopt appropriate rounding up
rules.  Let's tabulate the change for each frame to remove all ambiguity:

                                    shift by
frame                    difference  n gates
-----                    ---------- --------
 1       EPH_ROW 1533.12    6.9        +7
 2       EPH_ROW 1535.51    4.49       +4     
 3       EPH_ROW 1545.37   -5.4        -5
 4       EPH_ROW 1533.99    6.0        +6
 5       EPH_ROW 1536.62    3.4        +3
 6       EPH_ROW 1543.57   -3.6        -4
 7       EPH_ROW 1533.99    6.0        +6
 8       EPH_ROW 1540.65   -0.7        -1
 9       EPH_ROW 1544.73   -4.7        -5
10       EPH_ROW 1533.6     6.4        +6
11       EPH_ROW 1542.37   -2.4        -2
12       EPH_ROW 1544.79   -4.79       -5
13       EPH_ROW 1535.35    4.65       +5
14       EPH_ROW 1542.32   -2.3        -2
15       EPH_ROW 1545.71   -5.7        -6
16       EPH_ROW 1535.31    4.7        +5
17       EPH_ROW 1543.44   -3.4        -3
18       EPH_ROW 1547.46   -7.46       -7
19       EPH_ROW 1534.57    5.4        +5
20       EPH_ROW 1541.58   -1.6        -2
21       EPH_ROW 1547.02   -7.0        -7
22       EPH_ROW 1535.98    4.0        +4
23       EPH_ROW 1542.84   -2.84       -3
24       EPH_ROW 1548.3    -8.3        -8
25       EPH_ROW 1535.62    4.38       +4
26       EPH_ROW 1544.08   -4.1        -4

This is a huge rdf file--it's taking a long time to transfer to intruder
for processing (rdf software on think isn't available yet due to the 
patches Richard is installing).  The file is about 62 Meg.  Yikes!  
I wish Mike Nolan had vignetted it more tightly (each frame is 300 Doppler 
bins x 2000 range gates).  The file took about 20 minutes to ftp.

I'm testing comvin on just two frames to start and then I'll go on to the rest.

lance@intruder:/tmp_mnt/home/lance [11] source jm8.ao.proc
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Image 0  Mean 0.096044  sdev 1.851726 count 537000
Image 0  Mean 0.107165  sdev 2.017557 count 537000

the comvin output puzzles me.  The center values don't seem to be right.  ??
The *spy files are each 3.5 Meg.  eek...  net connections today are slow.

Here's the first attempt:
group_rdf jm8.990801.cbr.rdf jm8.990801.cbr.grp1.rdf 1 1
group_rdf jm8.990801.cbr.rdf jm8.990801.cbr.grp2.rdf 2 2
comvin jm8.990801.cbr.grp1.rdf jm8.990801.cbr.grp1.vig.rdf 300 2000 150 1547
comvin jm8.990801.cbr.grp2.rdf jm8.990801.cbr.grp2.vig.rdf 300 2000 150 1544
#sum_rdf jm8.990801.cbr.grp.rdf jm8.990801.cbr.sum.rdf
acunorm jm8.990801.cbr.grp1.vig.rdf jm8.990801.cbr.nrm1.rdf 132 196 315 571
acunorm jm8.990801.cbr.grp2.vig.rdf jm8.990801.cbr.nrm2.rdf 132 196 315 571
rdf2spy jm8.990801.cbr.nrm1.rdf jm8.990801.cbr.nrm1.spy
rdf2spy jm8.990801.cbr.nrm2.rdf jm8.990801.cbr.nrm2.spy

This didn't do what I expected: the echoes are near the bottom of the 
frame and they're partially wrapped in range (i.e. the distal arc appears
at the top of the frame).  

The LE in the two images seems to differ by a few gates.  Should have tried this 
with the frames showing the most offset to really isolate it.  

frame    LE (using ~10 sigma points as a threshold)
-----    ------------------------------------------
1           1747 (zero based)
2           1749 (zero based)

 1          1747
24          1760  OK, I'm not doing this right.  Rats.  

Yes: eph_row may be ~1540, but that's not where the images are
centered.  It would make more sense to move the center point relative
to the middle row of the image, not relative to row 1540.

Richard got think working again so let's do all this there.

think:/data doesn't have enough space, so do this on /public/protected/lance/1999JM8/
instead.  

Back up a bit: do the image reduction on think without using comvin.
It's possible that the software on intruder couldn't handle such large
numbers of rows and columns.  Think is running even more slowly than
intruder.
          Current value      New value
 1          825 (zero based)   832
24          838 (zero based)   830

So adjusting the center gate using comvin should get the LE registered
to within a couple of gates.  So this won't be perfect but it'll be tolerable.  

One unsettling question: what if Mike Nolan didn't compute eph_row correctly?
We might not be able to tell except by doing checks like this one and looking
for gross discrepancies.  

Onward...

1    818
24   846  

The signs above are reversed.  Do it again one more time... (this is taking
about 10 minutes to work with two frames).  So once I get this going, I should
work on intruder for Aug 2==> ftp the file to intruder NOW.  

1    832
24   830  Bingo.  

The script took about 20 minutes to run.

DOY 214 (Aug 02)
----------------
Modify the DOY 213 script and run it on intruder.  I already ftped the file
over.  There are 28 runs.  

Mean: 594.65.  Round up to 595.  

                          diff  shift by
                          ----  --------
 1       EPH_ROW 578.87   16.1  -16
 2       EPH_ROW 595.09   -0.1    0
 3       EPH_ROW 580.21   14.8  -15
 4       EPH_ROW 596.31   -1.3   +1
 5       EPH_ROW 581.16   13.8  -14 
 6       EPH_ROW 596.73   -1.7   +2
 7       EPH_ROW 581.86   13.1  -13
 8       EPH_ROW 598.3    -3.3   +3
 9       EPH_ROW 584.18   10.8  -11
10       EPH_ROW 598.96   -4.0   +4
11       EPH_ROW 585.14    9.9  -10
12       EPH_ROW 599.65   -4.7   +5
13       EPH_ROW 584.63   10.4  -10
14       EPH_ROW 602.31   -7.3   +7
15       EPH_ROW 585.73    9.3   -9
16       EPH_ROW 603.9    -8.9   +9
17       EPH_ROW 588.35    6.7   -7
18       EPH_ROW 605.33  -10.3  +10
19       EPH_ROW 589.44    5.6   -6
20       EPH_ROW 607.48 -12.48  +12
21       EPH_ROW 590.01    5.0   -5
22       EPH_ROW 608.4   -13.4  +13
23       EPH_ROW 591.01    4.0   -4
24       EPH_ROW 608.98  -14.0  +14
25       EPH_ROW 593.35    1.7   -2
26       EPH_ROW 610.06  -15.1  +15
27       EPH_ROW 594.07    0.9   +1
28       EPH_ROW 610.71  -15.7  +16

This took about 15 minutes to run on intruder--modestly faster than on think.

Here's the script (Note: there are bugs! I didn't realize that when I ran this):

group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp1.rdf 1 1
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp2.rdf 2 2
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp3.rdf 3 3
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp4.rdf 4 4
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp5.rdf 5 5
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp6.rdf 6 6
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp7.rdf 7 7
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp8.rdf 8 8
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp9.rdf 9 9
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp10.rdf 10 10
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp11.rdf 11 11
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp12.rdf 12 12
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp13.rdf 13 13
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp14.rdf 14 14
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp15.rdf 15 15
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp16.rdf 16 16
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp17.rdf 17 17
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp18.rdf 18 18
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp19.rdf 19 19
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp20.rdf 20 20
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp21.rdf 21 21
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp22.rdf 22 22
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp23.rdf 23 23
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp24.rdf 24 24
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp25.rdf 25 25
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 26 26
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 27 27
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 28 28

comvin jm8.990802.cbr.grp1.rdf  jm8.990802.cbr.vig1.rdf  300 1500 150 734
comvin jm8.990802.cbr.grp2.rdf  jm8.990802.cbr.vig2.rdf  300 1500 150 750
comvin jm8.990802.cbr.grp3.rdf  jm8.990802.cbr.vig3.rdf  300 1500 150 735
comvin jm8.990802.cbr.grp4.rdf  jm8.990802.cbr.vig4.rdf  300 1500 150 751
comvin jm8.990802.cbr.grp5.rdf  jm8.990802.cbr.vig5.rdf  300 1500 150 736
comvin jm8.990802.cbr.grp6.rdf  jm8.990802.cbr.vig6.rdf  300 1500 150 752
comvin jm8.990802.cbr.grp7.rdf  jm8.990802.cbr.vig7.rdf  300 1500 150 737
comvin jm8.990802.cbr.grp8.rdf  jm8.990802.cbr.vig8.rdf  300 1500 150 753
comvin jm8.990802.cbr.grp9.rdf  jm8.990802.cbr.vig9.rdf  300 1500 150 739
comvin jm8.990802.cbr.grp10.rdf jm8.990802.cbr.vig10.rdf 300 1500 150 754
comvin jm8.990802.cbr.grp11.rdf jm8.990802.cbr.vig11.rdf 300 1500 150 740
comvin jm8.990802.cbr.grp12.rdf jm8.990802.cbr.vig12.rdf 300 1500 150 755
comvin jm8.990802.cbr.grp13.rdf jm8.990802.cbr.vig13.rdf 300 1500 150 740
comvin jm8.990802.cbr.grp14.rdf jm8.990802.cbr.vig14.rdf 300 1500 150 757
comvin jm8.990802.cbr.grp15.rdf jm8.990802.cbr.vig15.rdf 300 1500 150 741
comvin jm8.990802.cbr.grp16.rdf jm8.990802.cbr.vig16.rdf 300 1500 150 759
comvin jm8.990802.cbr.grp17.rdf jm8.990802.cbr.vig17.rdf 300 1500 150 743
comvin jm8.990802.cbr.grp18.rdf jm8.990802.cbr.vig18.rdf 300 1500 150 760
comvin jm8.990802.cbr.grp19.rdf jm8.990802.cbr.vig19.rdf 300 1500 150 746
comvin jm8.990802.cbr.grp20.rdf jm8.990802.cbr.vig20.rdf 300 1500 150 762
comvin jm8.990802.cbr.grp21.rdf jm8.990802.cbr.vig21.rdf 300 1500 150 745
comvin jm8.990802.cbr.grp22.rdf jm8.990802.cbr.vig22.rdf 300 1500 150 763
comvin jm8.990802.cbr.grp23.rdf jm8.990802.cbr.vig23.rdf 300 1500 150 746
comvin jm8.990802.cbr.grp24.rdf jm8.990802.cbr.vig24.rdf 300 1500 150 764
comvin jm8.990802.cbr.grp25.rdf jm8.990802.cbr.vig25.rdf 300 1500 150 748
comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig26.rdf 300 1500 150 765
comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig27.rdf 300 1500 150 749
comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig28.rdf 300 1500 150 766

cat jm8.990802.cbr.vig1.rdf jm8.990802.cbr.vig2.rdf jm8.990802.cbr.vig3.rdf jm8.990802.cbr.vig4.rdf jm8.990802.cbr.vig5.rdf jm8.990802.cbr.vig6.rdf jm8.990802.cbr.vig7.rdf jm8.990802.cbr.vig8.rdf jm8.990802.cbr.vig9.rdf jm8.990802.cbr.vig10.rdf jm8.990802.cbr.vig11.rdf jm8.990802.cbr.vig12.rdf jm8.990802.cbr.vig13.rdf jm8.990802.cbr.vig14.rdf jm8.990802.cbr.vig15.rdf jm8.990802.cbr.vig16.rdf jm8.990802.cbr.vig17.rdf jm8.990802.cbr.vig18.rdf jm8.990802.cbr.vig19.rdf jm8.990802.cbr.vig20.rdf jm8.990802.cbr.vig21.rdf jm8.990802.cbr.vig22.rdf jm8.990802.cbr.vig23.rdf jm8.990802.cbr.vig24.rdf jm8.990802.cbr.vig25.rdf jm8.990802.cbr.vig26.rdf jm8.990802.cbr.vig27.rdf jm8.990802.cbr.vig28.rdf> jm8.990802.cbr.vig.rdf

sum_rdf jm8.990802.cbr.vig.rdf jm8.990802.cbr.sum.rdf
acunorm jm8.990802.cbr.sum.rdf  jm8.990802.cbr.nrm.rdf 98 381 231 936
rdf2spy jm8.990802.cbr.nrm.rdf jm8.990802.cbr.nrm.spy
rm *grp*
rm *vig*
rm *sum*

lance@intruder:/tmp_mnt/home/lance [39] source jm8.ao.aug2.proc
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Comvin using 475.000000,78.000000 as center
Image 0  Mean 4616486622.647219  sdev 5782545966.443227 count 376185

==> The normalized image doesn't look right: I think that the registration 
==> is wrong.  The image looks smeared and the peak SNR/pixel is only about 35;
==> it should be several hundred.  Hey-what's the deal with the comvin output?
==> it's not using the centers that I specified.  Run this on think instead.  

Let's double check that the images with the largest initial eph_row offsets
are registering correctly, and run this on think.  Doing this on think has the 
result that comvin outputs the correct center points.  Shoot--did I use comvin on
any of the other days? ==> NO.  comvin on intruder has a bug!  

Abandon image reduction on intruder...

Check the leading edges without using comvin to register the images: 
Frame   LE
-----   ---
1	470
28      472

This is puzzling: the difference should have been about 32 gates.  Did Mike 
already correct for the differences?

It turns out that some of the script was wrong.  Try it again...

think:/public/protected/lance/1999JM8/arecibo < 147 >  group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp1.rdf 1 1
think:/public/protected/lance/1999JM8/arecibo < 148 > group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp28.rdf 28 28
think:/public/protected/lance/1999JM8/arecibo < 149 > comvin jm8.990802.cbr.grp1.rdf  jm8.990802.cbr.vig1.rdf  300 1500 150 734
Comvin using 150.000000,734.000000 as center
think:/public/protected/lance/1999JM8/arecibo < 150 > comvin jm8.990802.cbr.grp28.rdf jm8.990802.cbr.vig28.rdf 300 1500 150 766
Comvin using 150.000000,766.000000 as center
think:/public/protected/lance/1999JM8/arecibo < 151 > acunorm -i jm8.990802.cbr.vig1.rdf  -o jm8.990802.cbr.nrm1.rdf -l 98 -t 381 -r 231 -b 936
Image 0  Mean 3839894729.312627  sdev 3827196651.573207 count 376185
think:/public/protected/lance/1999JM8/arecibo < 152 > acunorm -i jm8.990802.cbr.vig28.rdf -o jm8.990802.cbr.nrm28.rdf -l 98 -t 381 -r 231 -b 936
Image 0  Mean 4077812004.792430  sdev 4067332671.969527 count 376185

This matches the LE to within 2-3 gates.  The reason for the discrepancy before
was that I'm tired and that I didn't realized that I had corrected for the differences
in eph_row.

OK...fire away with the script again.  For the record, here it is:

group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp1.rdf 1 1
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp2.rdf 2 2
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp3.rdf 3 3
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp4.rdf 4 4
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp5.rdf 5 5
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp6.rdf 6 6
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp7.rdf 7 7
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp8.rdf 8 8
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp9.rdf 9 9
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp10.rdf 10 10
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp11.rdf 11 11
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp12.rdf 12 12
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp13.rdf 13 13
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp14.rdf 14 14
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp15.rdf 15 15
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp16.rdf 16 16
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp17.rdf 17 17
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp18.rdf 18 18
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp19.rdf 19 19
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp20.rdf 20 20
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp21.rdf 21 21
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp22.rdf 22 22
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp23.rdf 23 23
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp24.rdf 24 24
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp25.rdf 25 25
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 26 26
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp27.rdf 27 27
group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp28.rdf 28 28

comvin jm8.990802.cbr.grp1.rdf  jm8.990802.cbr.vig1.rdf  300 1500 150 734
comvin jm8.990802.cbr.grp2.rdf  jm8.990802.cbr.vig2.rdf  300 1500 150 750
comvin jm8.990802.cbr.grp3.rdf  jm8.990802.cbr.vig3.rdf  300 1500 150 735
comvin jm8.990802.cbr.grp4.rdf  jm8.990802.cbr.vig4.rdf  300 1500 150 751
comvin jm8.990802.cbr.grp5.rdf  jm8.990802.cbr.vig5.rdf  300 1500 150 736
comvin jm8.990802.cbr.grp6.rdf  jm8.990802.cbr.vig6.rdf  300 1500 150 752
comvin jm8.990802.cbr.grp7.rdf  jm8.990802.cbr.vig7.rdf  300 1500 150 737
comvin jm8.990802.cbr.grp8.rdf  jm8.990802.cbr.vig8.rdf  300 1500 150 753
comvin jm8.990802.cbr.grp9.rdf  jm8.990802.cbr.vig9.rdf  300 1500 150 739
comvin jm8.990802.cbr.grp10.rdf jm8.990802.cbr.vig10.rdf 300 1500 150 754
comvin jm8.990802.cbr.grp11.rdf jm8.990802.cbr.vig11.rdf 300 1500 150 740
comvin jm8.990802.cbr.grp12.rdf jm8.990802.cbr.vig12.rdf 300 1500 150 755
comvin jm8.990802.cbr.grp13.rdf jm8.990802.cbr.vig13.rdf 300 1500 150 740
comvin jm8.990802.cbr.grp14.rdf jm8.990802.cbr.vig14.rdf 300 1500 150 757
comvin jm8.990802.cbr.grp15.rdf jm8.990802.cbr.vig15.rdf 300 1500 150 741
comvin jm8.990802.cbr.grp16.rdf jm8.990802.cbr.vig16.rdf 300 1500 150 759
comvin jm8.990802.cbr.grp17.rdf jm8.990802.cbr.vig17.rdf 300 1500 150 743
comvin jm8.990802.cbr.grp18.rdf jm8.990802.cbr.vig18.rdf 300 1500 150 760
comvin jm8.990802.cbr.grp19.rdf jm8.990802.cbr.vig19.rdf 300 1500 150 746
comvin jm8.990802.cbr.grp20.rdf jm8.990802.cbr.vig20.rdf 300 1500 150 762
comvin jm8.990802.cbr.grp21.rdf jm8.990802.cbr.vig21.rdf 300 1500 150 745
comvin jm8.990802.cbr.grp22.rdf jm8.990802.cbr.vig22.rdf 300 1500 150 763
comvin jm8.990802.cbr.grp23.rdf jm8.990802.cbr.vig23.rdf 300 1500 150 746
comvin jm8.990802.cbr.grp24.rdf jm8.990802.cbr.vig24.rdf 300 1500 150 764
comvin jm8.990802.cbr.grp25.rdf jm8.990802.cbr.vig25.rdf 300 1500 150 748
comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig26.rdf 300 1500 150 765
comvin jm8.990802.cbr.grp27.rdf jm8.990802.cbr.vig27.rdf 300 1500 150 749
comvin jm8.990802.cbr.grp28.rdf jm8.990802.cbr.vig28.rdf 300 1500 150 766

cat jm8.990802.cbr.vig1.rdf jm8.990802.cbr.vig2.rdf jm8.990802.cbr.vig3.rdf jm8.990802.cbr.vig4.rdf jm8.990802.cbr.vig5.rdf jm8.990802.cbr.vig6.rdf jm8.990802.cbr.vig7.rdf jm8.990802.cbr.vig8.rdf jm8.990802.cbr.vig9.rdf jm8.990802.cbr.vig10.rdf jm8.990802.cbr.vig11.rdf jm8.990802.cbr.vig12.rdf jm8.990802.cbr.vig13.rdf jm8.990802.cbr.vig14.rdf jm8.990802.cbr.vig15.rdf jm8.990802.cbr.vig16.rdf jm8.990802.cbr.vig17.rdf jm8.990802.cbr.vig18.rdf jm8.990802.cbr.vig19.rdf jm8.990802.cbr.vig20.rdf jm8.990802.cbr.vig21.rdf jm8.990802.cbr.vig22.rdf jm8.990802.cbr.vig23.rdf jm8.990802.cbr.vig24.rdf jm8.990802.cbr.vig25.rdf jm8.990802.cbr.vig26.rdf jm8.990802.cbr.vig27.rdf jm8.990802.cbr.vig28.rdf> jm8.990802.cbr.vig.rdf

sum_rdf jm8.990802.cbr.vig.rdf jm8.990802.cbr.sum.rdf
acunorm -i jm8.990802.cbr.sum.rdf  -o jm8.990802.cbr.nrm.rdf -l 98 -t 381 -r 231 -b 936
rdf2spy jm8.990802.cbr.nrm.rdf jm8.990802.cbr.nrm.spy
rm *grp*
rm *vig*
rm *sum*

think:/public/protected/lance/1999JM8/arecibo < 169 > source jm8.ao.aug2.proc
Comvin using 150.000000,734.000000 as center
Comvin using 150.000000,750.000000 as center
Comvin using 150.000000,735.000000 as center
Comvin using 150.000000,751.000000 as center
Comvin using 150.000000,736.000000 as center
Comvin using 150.000000,752.000000 as center
Comvin using 150.000000,737.000000 as center
Comvin using 150.000000,753.000000 as center
Comvin using 150.000000,739.000000 as center
Comvin using 150.000000,754.000000 as center
Comvin using 150.000000,740.000000 as center
Comvin using 150.000000,755.000000 as center
Comvin using 150.000000,740.000000 as center
Comvin using 150.000000,757.000000 as center
Comvin using 150.000000,741.000000 as center
Comvin using 150.000000,759.000000 as center
Comvin using 150.000000,743.000000 as center
Comvin using 150.000000,760.000000 as center
Comvin using 150.000000,746.000000 as center
Comvin using 150.000000,762.000000 as center
Comvin using 150.000000,745.000000 as center
Comvin using 150.000000,763.000000 as center
Comvin using 150.000000,746.000000 as center
Comvin using 150.000000,764.000000 as center
Comvin using 150.000000,748.000000 as center
Comvin using 150.000000,765.000000 as center
Comvin using 150.000000,749.000000 as center
Comvin using 150.000000,766.000000 as center
Image 0  Mean 3888535799.712333  sdev 735366146.677721 count 376185

There's detail in this image that was not obvious in Jean-Luc's data. 
For example, there are several craters that I haven't noticed before.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

CHECK THE DTIME AND YEAR TAGS ON THE NORMALIZED IMAGES
     file                 year   dtime    UTC     eph_row  should be (mean)
     ----                 ----   -----    ---     -------  ---------
jm8.990801.cbr.nrm.rdf    1999   46264  12:51:04  1533.12  1540.3
jm8.990802.cbr.nrm.rdf    1999   46924  13 02 04  578.87    594.7
jm8.990803.cbr.nrm.rdf    1999   45792  12 43 12  400.54    401.0
jm8.990804.cbr.nrm.rdf    1999   48360  13 26 00  401.33    401.1
jm8.990805.cbr.nrm.rdf    1999   43094  11 58 14  401.37    400.9
jm8.990806.cbr.nrm.rdf    1999   45230  12 33 50  400.62    401.0
jm8.990809.cbr.nrm.rdf    1999   38795  10 46 35  400.79    401.0

dtime values are correct: they refer to the first rcsta, NOT 
the mid-epoch.  eph_row values refer to the first one, not to the mean.

I modified eph_row in the cbr files to match the values listed above.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

INSPECT THE CBR IMAGES: MAKE SURE THEY MATCH THE GSB IMAGES

COMBINE THE CBR OC AND SC IMAGES INTO ONE FILE

CBR DATA TO NORMALIZE:
 Aug 1 done
 Aug 2 done
 Aug 3 done
 Aug 4 done
 Aug 5 done
 Aug 6 done
 Aug 9 done

MAKE SURE THAT THE TIME TAGS ON THE SUMMED, NORMALIZED IMAGES ARE CORRECT

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

                        1999 December 20

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

Things to do to with the images before giving them to Scott:

1. Tabulate:
      date: DONE
      DOY: DONE
      file names: DONE
      time spans: DONE
      eph_row: DONE
      eph_col: DONE
      solution number: DONE
      Doppler sense: DONE
      resolution: DONE
      size of image (row x col): DONE
2. Make sure time tags, eph_row, and eph_col (if applicable) are correct. DONE
3. Indicate what the times mean: rcsta, rcend, etc.  DONE

** THERE'S SOMETHING WRONG WITH THE AUG 3 IMAGE!  See extra echo power to the
** right of the LE.  Perhaps one frame had a different offset?  Perhaps I screwed
** it up with the summing/vignetting.

Also see (sincx)^2 effects on Aug 3 and 5.  I hope Scott has some method
of dealing with that.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

eph_col and eph_row for Goldstone images
========================================

Jul 20
------
eph_col: DC is in gate 32.  TXoff = 2.3 Hz using 0.1 Hz/bin. -> txoff = 23 bins
relative to DC.  32-23 = 9 or bin 8 (zero-based) 

eph_row: CLT is in gate 13, one-based.  I'm using zero-based numbers, so 
that puts it into gate 12

Jul 21
------
eph_col: txoff = + 5 Hz or +50 bins relative to DC.  So 128-50=78 one-based 
or bin 77 zero-based.

eph_row: clt is in gate 13 (one-based), but we inserted a +30 us range
offset, putting eph_row into gate 43 one-based or gate 42 zero-based.

Jul 23
------
eph_col: txoff = +5 Hz.  dfreq = 0.075 Hz/bin so in bins the offset is
5 Hz/0.075 Hz/bin = 66.7 bins.  128-66.7=61.3 one-based or 60.3 zero-based.

eph_row: txoff = +25 gates.  CLT was in gate 17 (one based).  So that puts
us at 17+25=42 gates (one-based) or 41 (zero-based).  

Jul 24
------
eph_col: txoff =+4 Hz or 4 Hz/0.075 Hz/bin = 53.4 bins.  128-53.4=74.6 
one-based or 73.6 zero-based.

eph_row: txoff = +25 us (+50 gates). CLT = 17 (one-based), so 17+50=67
one-based or 66 zero-based.

Jul 27
------
eph_col: txoff = +2.5 Hz or 2.5/0.04982 Hz/bin = 50.2 bins.  
128-50.2=77.8 bins one based or 76.8 bins zero-based.

eph_row: txoff=+150 range gates. CLT = 22, so 22+150=172 one
based or 171 zero-based.  

Jul 28
------
eph_col: txoff = +2.5 Hz/(0.04982 Hz/bin) = 50.2 bins.  Same as the
day before.

eph_row: txoff=+100 gates.  clt = 22.  => gate 122 one-based or
121 zero-based.  

Jul 31
------
eph_col: txoff = + 2.5 Hz. 2.5 Hz/(0.05002 Hz/bin) = 49.98 bins
128-49.98=78.02 bins one-based or 77.02 bins zero-based.

eph_row: txoff = -100 gates.  clt = 34.  34-100=-66.  255-66=189
one-based or 188 zero-based.  

Aug 1
-----
eph_col: txoff = +3 Hz.  3/(0.05002) = 59.98 bins. 128-59.98=68.02
or 67.02 zero-based.

eph_row: txoff = +120 gates.  clt = gate 34.  120+34=154 one-based
or 153 zero-based.  

Aug 7
-----
eph_col: txoff = +3 Hz.  3/(0.074725) = 40.1 bins. 128-40.1 = 87.9
one-based or 86.9 zero-based.

eph_row: CLT = gate 22.  txoff=+100 gates. total = 122 one based or
121 zero-based.  

Aug 8
-----
eph_col: txoff = +3 Hz, so same result as day before.

eph_row: CLT = 22. txoff = +100 gates, so same result as day before

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I spent several hours preparing the table: 1999JM8.images.summary to help Scott
and us understand the processing of the reduced images.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I have not examined the GSB data in detail yet.  There were problems with it
on the first couple of days that I think will be more painful than the problems
with the CBR data, plus the echo strengths will probably be down by a few dB
relative to the CBR data.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Aug 3 Arecibo image
-------------------
This image looks like there are one or two frames that have a Doppler offset
relative to the others.  There are 31 frames total.  Mike's file Readme* 
doesn't indicate that he did anything different with any of the files, but
perhaps he accidentally vignetted some differently.  

One way to find out would be to look at each frame and check for ones that are 
shifted.  That will be time-consuming and tedious.  

This is different from the ghosts I saw in the Goldstone images, so I don't 
think it's an I & Q problem.  It's not (sincx)^2 either; there's plenty of that
in the image but it takes on a different morphology from the "ghost." 

Other possibilities: 
1. check the GSB data

The gif file that Jean-Luc prepared shows sincx effects but no other artifacts
or obvious problems.  That's not the same as working with the files themselves,
though.

2. Problem with the CBR?
How can we trace that?  

There are 31 frames in the file but my observing notes indicate that we got
only 30 runs.  Perhaps there's a partial run included?  It seems that one of 
the final two runs is included--when the target was out of the beam.  Let's 
repeat the reduction excluding that frame.  

Script:
group_rdf jm8.990803.cbr.rdf jm8.990803.cbr.grp.rdf 1 30
sum_rdf jm8.990803.cbr.grp.rdf jm8.990803.cbr.sum.rdf
acunorm -i jm8.990803.cbr.sum.rdf -o jm8.990803.cbr.nrm.rdf -l 83 -t 267 -r 204 -b 602
rdf2spy jm8.990803.cbr.nrm.rdf jm8.990803.cbr.nrm.dud.spy
rm *grp*
rm *sum*

think:/public/protected/lance/1999JM8/arecibo < 63 > source jm8.ao.proc
Image 0  Mean 4167212422.089890  sdev 761518269.186882 count 199465

That solved the problem.  Interesting...  

I ftped the new (good) files to reason from think and got rid of the bad ones.

Just for kicks, let's take a look at that final frame. --> There's a complete 
image there but it's weak.  

Onward...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I sent Scott and Steve email describing everything in considerable detail.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Let's back up the files onto think:/public/protected.  (Note: we don't have
a functional cd burner).  Alternatively, I could do a backup onto exabyte 
tape.  

Arecibo
reason:/data/ast5/1999JM8/arecibo/proc/rng < 186 > du -ks reduced_images/
9513    reduced_images

Goldstone
reason:/data/ast5/1999JM8/proc/rng < 190 > du -ks reduced_images/
4484    reduced_images

So the reduced rdf files are about 14 Meg total.  There's more than 900 Meg of space
on think:/public/protected, so put them there first.

think:/public/protected/lance/1999JM8/reduced_images_backup/

Back them up onto intruder:/d1/1999JM8/proc/reduced_images_backup/

I'm backing everything up onto exabyte tapes too--by using Mike Thomas' script
/etc/dump4.  That backs up /ast3, /ast4, /ast5/ and /ast6.  The JM8 data are on
/ast5 and /ast6.  ==> Didn't work.  Back up the JM8 directories individually
instead:

reason:/data/ast5/1999JM8 < 29 > /tar cvf /dev/rmt/0n . 
reason:/data/ast6/1999JM8_arecibo < 31 > tar cvf /dev/rmt/0n .
reason:/data/ast6/1999JM8_arecibo < 33 > mt -f /dev/rmt/0n rewoffl
reason:/data/ast5/1999JM8 < 40 > tar tvf /dev/rmt/0n > analysis/1999JM8_122099_1.1
I meant to put that in /archive/..

This seems to indicate that only the Arecibo files are on the tape.  Did they
overwrite the Goldstone files?  No--when I repeat the tar tvf command and write
it to the xterm window all the Goldstone files show up.  That's odd...

What happened was that I entered ^C to stop it while tar was displaying the 
contents of /data/ast5/1999JM8/ files.  When I started and told it to write 
the results to a file, I forgot to rewind the tape, so it wrote only the 
/data/ast6/1999JM8_arecibo/ files.  All the files are there and they're now
written to ../ast5/1999JM8/archives/1999JM8_122099_1.1

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

Summed, normalized, and vignetted Goldstone images
--------------------------------------------------

File                    Contents       dtime (seconds)  time (UTC)    interval (h)
----                    --------       ---------------  ----------    ------------
jm20103.nrm.vig.rdf     frames  1-  9  10221-10676      025021-025756    0.13

jm20203.nrm.vig.rdf     frames  1-112  64751-67472      175911-184432    0.76

jm20403.nrm.vig.rdf     frames  1- 69   3213- 5926      005333-013846    0.75

jm20511.nrm.vig.rdf     frames  1-191  64938-71960      180218-195920    1.95
jm20511.nrm1.vig.rdf    frames  1- 96  64938-68434      180218-190034    0.97
jm20511.nrm2.vig.rdf    frames 97-191  68448-71960      190048-195920    0.98

jm20803.nrm.vig.rdf     frames  1- 34   6628-10428      015028-025348    1.06

jm20903.nrm.vig.rdf     frames  1- 43  63064-68448      173104-190048    1.50
jm20903.nrm1.vig.rdf    frames  1- 22  63064-65887      173104-181807    0.78
jm20903.nrm2.vig.rdf    frames 23- 43  66011-68448      182011-190048    0.68

jm21205.nrm.vig.rdf     frames  3- 72  62735-71724      172535-195524    2.50
jm21205.nrm1.vig.rdf    frames  3- 25  62735-65424      172535-181024    0.75
jm21205.nrm2.vig.rdf    frames 26- 48  65548-68231      181228-185711    0.75
jm21205.nrm3.vig.rdf    frames 49- 72  68900-71724      190820-195524    0.78

jm21305.nrm.vig.rdf     frames  6-102  45258-57549      123418-155909    3.41
jm21305.nrm1.vig.rdf    frames  6- 29  45258-48135      123418-132215    0.80
jm21305.nrm2.vig.rdf    frames 30- 53  48262-51434      132422-141714    0.88
jm21305.nrm3.vig.rdf    frames 54- 77  51557-54429      141917-150709    0.80
jm21305.nrm4.vig.rdf    frames 78-102  54557-57549      150917-155909    0.83

jm21903.nrm.vig.rdf     frames  5- 28  62816-65038      172656-180358    0.62

jm22003.nrm.vig.rdf     frames  1-250  42850-51758      115410-142251    2.48
jm22003.nrm1.vig.rdf    frames  1- 83  42850-45761      125077-124241    0.81
jm22003.nrm2.vig.rdf    frames 84-166  45775-48815      124255-133335    0.84
jm22003.nrm3.vig.rdf    frames167-250  48828-51758      133348-142238    0.81

jm22004.nrm.vig.rdf     frames  1-264  52206-61683      143006-170803    2.63
jm22004.nrm1.vig.rdf    frames  1- 88  52206-55296      143006-152136    0.86
jm22004.nrm2.vig.rdf    frames 89-176  55309-58550      152149-161550    0.90
jm22004.nrm3.vig.rdf    frames177-250  58564-61683      161604-170803    0.87

jm22007.nrm.vig.rdf     frames  1-212  61994-69568      171314-191928    2.10
jm22007.nrm1.vig.rdf    frames  1- 71  61994-64489      171314-175449    0.69
jm22007.nrm2.vig.rdf    frames 72-142  64502-67032      175502-183712    0.70
jm22007.nrm3.vig.rdf    frames143-212  67162-69568      183922-191928    0.67

Summed, normalized, and vignetted Arecibo images
------------------------------------------------

     file                 year   dtime    UTC     eph_row  should be (mean)
     ----                 ----   -----    ---     -------  ---------
jm8.990801.cbr.nrm.rdf    1999   46264  12:51:04  1533.12  1540.3
jm8.990802.cbr.nrm.rdf    1999   46924  13 02 04  578.87    594.7
jm8.990803.cbr.nrm.rdf    1999   45792  12 43 12  400.54    401.0
jm8.990804.cbr.nrm.rdf    1999   48360  13 26 00  401.33    401.1
jm8.990805.cbr.nrm.rdf    1999   43094  11 58 14  401.37    400.9
jm8.990806.cbr.nrm.rdf    1999   45230  12 33 50  400.62    401.0
jm8.990809.cbr.nrm.rdf    1999   38795  10 46 35  400.79    401.0

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

                        2000 January 3 & 4

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

Before leaving JPL for the holiday vacation, I tabulated the delay-Doppler imaging
results in the file:

1999JM8.images.summary

I emailed copies of that file to Scott and Steve.

Also before the holidays, I revised the brief description I wrote in October 
describing observing and data reduction at Goldstone.  This is the first such
guide in about four years since Dave Mitchell wrote one largely for my benefit.
The Goldstone system has changed substantially during those four years.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Tabulate the number of looks in each delay-Doppler image
========================================================

The objective is to add this information to 1999JM8.images.summary, which I 
intend to post on a website to facilitate communication with co-authors.

Arecibo
-------
Mike Nolan chose FFTs so that there is one look/image, so this is trivial.

Goldstone
---------
On some days we got one look/image but on others there were multiple looks.

Date    Setup              frames   looks/frame  looks
----    -----              ------   -----------  -----
Jul 20  1 us x 0.1 Hz        9           2         18
Jul 21  1 us x 0.1 Hz      112           1        112
Jul 23  1/2 us x 0.075 Hz   68           1         68
Jul 24  1/2 us x 0.075 Hz  191           1        191 ***
Jul 27  1/4 us x 0.05 Hz    34           1         34
Jul 28  1/4 us x 0.05 Hz    43           1         43
Jul 31  1/8 us x 0.05 Hz    70           1         70
Aug 01  1/8 us x 0.05 Hz    97           1         97
Aug 07  1/4 us x 0.075 Hz   24           2         48
Aug 08  1/4 us x 0.075 Hz  250           1        250
                           264           1        264
                           212           1        212
 
My processing script indicates that I used only the first 49 out of 191 
frames from DOY 205 (July 24) in file jm20511.  Why?  ==> I mistook 
runs and frames.  There are 49 runs with a total of 191 frames.  

==> Repeat the reduction and then send email to Scott.

DOY 205 (July 24)
-----------------
We got 49 RUNS spanning 2.0 h for a total of 191 looks.  Prepare one summed image 
and two spanning about 1 hour each.  

script on THINK:

# jm20511: sum into one file

group_rdf jm20511.rdf jm20511.grp.rdf 1 191
sum_rdf jm20511.grp.rdf jm20511.sum.rdf
acunorm -i jm20511.sum.rdf -o jm20511.nrm.rdf -l 177 -t 3 -r 216 -b 84
comvin jm20511.nrm.rdf jm20511.nrm.vig.rdf 128 255 193 127
rdf2spy jm20511.nrm.vig.rdf jm20511.nrm.vig.spy
rm *grp*
rm *sum*

# Sum into two groups

# Group 1
group_rdf jm20511.rdf jm20511.grp1.rdf 1 95
sum_rdf jm20511.grp1.rdf jm20511.sum1.rdf
acunorm -i jm20511.sum1.rdf -o jm20511.nrm1.rdf -l 177 -t 3 -r 216 -b 84
comvin jm20511.nrm1.rdf jm20511.nrm1.vig.rdf 128 255 193 127
rdf2spy jm20511.nrm1.vig.rdf jm20511.nrm1.vig.spy
rm *grp*
rm *sum*

# Group 2
group_rdf jm20511.rdf jm20511.grp2.rdf 96 191
sum_rdf jm20511.grp2.rdf jm20511.sum2.rdf
acunorm -i jm20511.sum2.rdf -o jm20511.nrm2.rdf -l 177 -t 3 -r 216 -b 84
comvin jm20511.nrm2.rdf jm20511.nrm2.vig.rdf 128 255 193 127
rdf2spy jm20511.nrm2.vig.rdf jm20511.nrm2.vig.spy
rm *grp*
rm *sum*

can't do this on think:/data/lance/1999JM8/Goldstone--/data is nearly full.
Switch to /public/protected/lance/1999JM8/ instead.  

think:/public/protected/lance/1999JM8/goldstone < 81 > source jm8proc
Image 0  Mean 58105508.034127  sdev 4229026.982174 count 62121
Comvin using 193.000000,127.000000 as center
Image 0  Mean 58929017.335909  sdev 6057004.624396 count 62121
Comvin using 193.000000,127.000000 as center
Image 0  Mean 57290576.846992  sdev 5864328.191532 count 62121
Comvin using 193.000000,127.000000 as center

...Done.  I have divided the resulting files into three categories and
separated them into appropriate directories:

reduced_images/
unvignetted_reduced_images/
spyglass_files/

I sent email to Scott.  This time he replied.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Prepare an ephemeris covering the dates when we observed JM8
------------------------------------------------------------

For the following table, I computed the mid-epochs of the observations
and then rounded them to the nearest 10-minute mark.  The Aug 1 observations
were conducted at both telescopes but I adopted the Goldstone interval
because those observations completely encompassed the Arecibo observations.
The RA, DEC, and delta values differ in the 2nd - 4th significant digits
depending on whether or not one chooses Arecibo or Goldstone as the
observatory.
                                                                   mid-epoch
DOY      DATE      RA (deg)   DEC (deg)   delta (AU)  Observatory   (UTC)
---      ----      --------   ---------   ----------  -----------  ---------
199-200  Jul 18-19 186.86316  59.91692  0.0986950379      G        02:10
201      Jul 20    182.49773  61.31689  0.0927759882      G        03 10
202      Jul 21    173.48589  63.45410  0.0839631015      G        18 10
204      Jul 23    163.49301  64.87432  0.0774280241      G        01 10
205      Jul 24    146.08152  65.54093  0.0696525769      G        18 30
208      Jul 27    118.34826  61.99643  0.0615591099      G        02 10
209      Jul 28    101.40668  55.57469  0.0579923112      G        18 10
212      Jul 31     81.69768  38.71527  0.0576216663      G        18 30
213      Aug  1     78.29506  33.91821  0.0588849962      G        14 00
214      Aug  2     74.83822  28.41457  0.0610769255      A        13 20
215      Aug  3     71.97869  23.19617  0.0639870786      A        13 00
216      Aug  4     69.51887  18.27725  0.0676252294      A        13 30
217      Aug  5     67.57866  14.10063  0.0715526777      A        12 40
218      Aug  6     65.85205  10.21789  0.0760713690      A        12 50
219      Aug  7     64.11012   6.15781  0.0819247971      G        17 40
220      Aug  8     62.98709   3.44577  0.0866410327      G        15 40
221      Aug  9     62.08343   1.25406  0.0910521650      A        11 30

Check the sky motion:

reason:/data/ast5/1999JM8/analysis < 11 > angle
  
Enter RA1 (deg):
186.86
Enter DEC1 (deg):
59.92
  
Enter RA2 (deg):
62.08
Enter DEC2 (deg):
1.25
  
Angle =   105.4833

The sky motion during the imaging (Jul 20-Aug 9) is a bit less:

reason:/data/ast5/1999JM8/analysis < 12 > angle
  
Enter RA1 (deg):
182.5
Enter DEC1 (deg):
61.32
  
Enter RA2 (deg):
62.08
Enter DEC2 (deg):
1.25
  
Angle =   102.9325

This will provide excellent geometric leverage with the shape modeling.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I completed the table of delay-Doppler dispersions (using contiguous pixels
above the 2-sigma level). 

The Arecibo Doppler dispersions don't vary by much: 0.88-1.01 Hz  
The Arecibo delay disperions vary considerably: 3.47-5.27 km.

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

                        2000 January 17

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

Go back and normalize the SC images and then create ratio images.

Creating normalized SC images will be straightforward because I already
have a Perl script to do everything after minor modifications.  The script
is:

jm8.ao.sc.proc,

which was modified from jm8.ao.proc.

Do the reduction on think due to the lack of rdf imaging software on reason.
Use think:/public/protected/lance/1999JM8/arecibo/

I'm going to reduce Aug 1 first since--that's the data that requires the
most registration.

This is crunching along slowly on think.  

Result: nice SC image.  Looks good--I opened it with Spyglass Transform.  

Forge ahead with images from the other days.  I'm doing them all in one fell swoop.

think:/public/protected/lance/1999JM8/arecibo < 92 > source jm8.ao.sc.proc
Aug 4: Image 0  Mean 0.001214  sdev 0.447209 count 191562
Aug 3: Image 0  Mean 4182808474.133266  sdev 761408562.809779 count 199465
Aug 5: Image 0  Mean 4780336850.023087  sdev 808176734.420315 count 187294
Aug 6: Image 0  Mean 5133356300.264912  sdev 1420332355.947895 count 256508
Aug 9: Image 0  Mean 6245801645.364065  sdev 1248579928.684739 count 251375

Where is the image for August 2?  ==> It's not in the script so it wasn't 
reduced.  Odd... ==> It turns out that I wrote a separate script in December
to reduce the Aug 1 and 2 files due to the problems with eph_row.  I added
the oc script to jm8.ao.sc.proc, revised it to handle sc images, and 
then ran it on think.  It's chugging along... 

think:/public/protected/lance/1999JM8/arecibo < 108 > source jm8.ao.sc.proc
Comvin using 150.000000,734.000000 as center
Comvin using 150.000000,750.000000 as center
Comvin using 150.000000,735.000000 as center
Comvin using 150.000000,751.000000 as center
Comvin using 150.000000,736.000000 as center
Comvin using 150.000000,752.000000 as center
Comvin using 150.000000,737.000000 as center
Comvin using 150.000000,753.000000 as center
Comvin using 150.000000,739.000000 as center
Comvin using 150.000000,754.000000 as center
Comvin using 150.000000,740.000000 as center
Comvin using 150.000000,755.000000 as center
Comvin using 150.000000,740.000000 as center
Comvin using 150.000000,757.000000 as center
Comvin using 150.000000,741.000000 as center
Comvin using 150.000000,759.000000 as center
Comvin using 150.000000,743.000000 as center
Comvin using 150.000000,760.000000 as center
Comvin using 150.000000,746.000000 as center
Comvin using 150.000000,762.000000 as center
Comvin using 150.000000,745.000000 as center
Comvin using 150.000000,763.000000 as center
Comvin using 150.000000,746.000000 as center
Comvin using 150.000000,764.000000 as center
Comvin using 150.000000,748.000000 as center
Comvin using 150.000000,765.000000 as center
Comvin using 150.000000,749.000000 as center
Comvin using 150.000000,766.000000 as center
Image 0  Mean 3910581786.151558  sdev 737468887.314903 count 376185

This took roughly 20 minutes.

- - - - - - - - - - 

Vignette the reduced images further for ratio images
----------------------------------------------------

Before I really get into this, go back to the reduced and vignetted 
rdf files and vignette them even more.  They are much too large.

Additional vignetting is needed for:
Aug 1
Aug 2
Aug 3
Aug 4: less than on other days
Aug 5: Yes.  This day sets the horizontal vignetting
Aug 6: Yes.  This day sets the vertical vignetting
Aug 9: Yes, but less than on the first three days.

Make all images the same size (row x col)

Do the vignetting on think.  Means I need to ftp the files back over
from reason.  

I'll write the script to do the ratios in Perl and run it on rhyme/reason.

Using the images with the most range and Doppler pixels as a guide,
adopt row x col = 500 x 200.

Vignetting Centers:

Date    row (range)  col (Doppler)  Mid point
----    -----------  -------------  ---------
Aug 1    750-1249    50-249         1000,150
Aug 2    369- 868    50-249          619,150
Aug 3    150- 649    50-249          400,150
Aug 4    226- 725    80-279          476,180
Aug 5    186- 685    50-249          436,180
Aug 6    122- 621    80-279          372,180
Aug 9    164- 663   128-327          414,164

Since the images will be SC/OC, I'll map echo powers less than a threshold
level to 1 sigma in OC and to 0 (zero) sigma in SC.  ==> those pixels will
map to black.  The script will allow the user to select different thresholds.
Reasonable thresholds are 3, 5, or 10 sigma.  

Rethink that: if the same pixel in *either* image is less than some threshold,
then map it to black by mapping the SC pixel to zero sigma.  If the OC pixel
happens to be exactly zero, which is unlikely, then map it to one sigma.

The vignetting script is:
think:/public/protected/lance/1999JM8/arecibo/jm8.ao.vig.proc

comvin  jm8.990801.cbr.nrm.sc.rdf     jm8.990801.cbr.nrm.vig.sc.rdf  500 200 1000 150
comvin  jm8.990801.cbr.nrm.rdf        jm8.990801.cbr.nrm.vig.rdf     500 200 1000 150
rdf2spy jm8.990801.cbr.nrm.vig.sc.rdf jm8.990801.cbr.nrm.vig.sc.spy
rdf2spy jm8.990801.cbr.nrm.vig.rdf    jm8.990801.cbr.nrm.vig.spy

comvin  jm8.990802.cbr.nrm.sc.rdf     jm8.990802.cbr.nrm.vig.sc.rdf  500 200 619 150
comvin  jm8.990802.cbr.nrm.rdf        jm8.990802.cbr.nrm.vig.rdf     500 200 619 150
rdf2spy jm8.990802.cbr.nrm.vig.sc.rdf jm8.990802.cbr.nrm.vig.sc.spy
rdf2spy jm8.990802.cbr.nrm.vig.rdf    jm8.990802.cbr.nrm.vig.spy

comvin  jm8.990803.cbr.nrm.sc.rdf     jm8.990803.cbr.nrm.vig.sc.rdf  500 200 400 150
comvin  jm8.990803.cbr.nrm.rdf        jm8.990803.cbr.nrm.vig.rdf     500 200 400 150
rdf2spy jm8.990803.cbr.nrm.vig.sc.rdf jm8.990803.cbr.nrm.vig.sc.spy
rdf2spy jm8.990803.cbr.nrm.vig.rdf    jm8.990803.cbr.nrm.vig.spy

comvin  jm8.990804.cbr.nrm.sc.rdf     jm8.990804.cbr.nrm.vig.sc.rdf  500 200 476 180
comvin  jm8.990804.cbr.nrm.rdf        jm8.990804.cbr.nrm.vig.rdf     500 200 476 180
rdf2spy jm8.990804.cbr.nrm.vig.sc.rdf jm8.990804.cbr.nrm.vig.sc.spy
rdf2spy jm8.990804.cbr.nrm.vig.rdf    jm8.990804.cbr.nrm.vig.spy

comvin  jm8.990805.cbr.nrm.sc.rdf     jm8.990805.cbr.nrm.vig.sc.rdf  500 200 436 150
comvin  jm8.990805.cbr.nrm.rdf        jm8.990805.cbr.nrm.vig.rdf     500 200 436 150
rdf2spy jm8.990805.cbr.nrm.vig.sc.rdf jm8.990805.cbr.nrm.vig.sc.spy
rdf2spy jm8.990805.cbr.nrm.vig.rdf    jm8.990805.cbr.nrm.vig.spy

comvin  jm8.990806.cbr.nrm.sc.rdf     jm8.990806.cbr.nrm.vig.sc.rdf  500 200 372 180
comvin  jm8.990806.cbr.nrm.rdf        jm8.990806.cbr.nrm.vig.rdf     500 200 372 180
rdf2spy jm8.990806.cbr.nrm.vig.sc.rdf jm8.990806.cbr.nrm.vig.sc.spy
rdf2spy jm8.990806.cbr.nrm.vig.rdf    jm8.990806.cbr.nrm.vig.spy

comvin  jm8.990809.cbr.nrm.sc.rdf     jm8.990809.cbr.nrm.vig.sc.rdf  500 200 414 164
comvin  jm8.990809.cbr.nrm.rdf        jm8.990809.cbr.nrm.vig.rdf     500 200 414 164
rdf2spy jm8.990809.cbr.nrm.vig.sc.rdf jm8.990809.cbr.nrm.vig.sc.spy
rdf2spy jm8.990809.cbr.nrm.vig.rdf    jm8.990809.cbr.nrm.vig.spy

It turns out that I don't need to write a Perl script to compute ratio images:
Keith (?) already did it:

reason:/home/lance < 26 > ratioimg -h
Usage:  ratioimg -1 channel_1_file -2 channel_2_file -o output_ratio_file  -t threshold
         Inputs should have same numbers of corresponding, normalized frames

Presumably this means that channel 1 = SC, channel 2 = OC, and the threshold
is in standard deviations.  

ratioimg is also available on think.  

I've been testing ratioimg but I haven't gotten any ratio images.  I finally used 
rdf2spy to check the vignetted rdf files above and found that the one from Aug 1 
doesn't have the echo: it's just noise.  ??

Let's just use ratioimg on the original, unvignetted (but grouped, summed, and normalized)
files.

OK, it turns out that ratioimg IS working, but the stretch I was using made it
difficult to tell. This is largely due to the fact that I'm tired, so 
let's go get some rest. 

I did some tests and verified that the threshold is in sigmas. 
The ratio images will probably need logarithmic stretches.  

ratio.proc:

# convention: file 1 = OC and file 2 = SC

ratioimg -1 jm8.990801.cbr.nrm.rdf -2 jm8.990801.cbr.nrm.sc.rdf -o jm8.990801.cbr.scoc.2.rdf -t 2
rdf2spy     jm8.990801.cbr.scoc.2.rdf   jm8.990801.cbr.scoc.2.spy 

ratioimg -1 jm8.990802.cbr.nrm.rdf -2 jm8.990802.cbr.nrm.sc.rdf -o jm8.990802.cbr.scoc.2.rdf -t 2
rdf2spy     jm8.990802.cbr.scoc.2.rdf   jm8.990802.cbr.scoc.2.spy 

ratioimg -1 jm8.990803.cbr.nrm.rdf -2 jm8.990803.cbr.nrm.sc.rdf -o jm8.990803.cbr.scoc.2.rdf -t 2
rdf2spy     jm8.990803.cbr.scoc.2.rdf   jm8.990803.cbr.scoc.2.spy 

ratioimg -1 jm8.990804.cbr.nrm.rdf -2 jm8.990804.cbr.nrm.sc.rdf -o jm8.990804.cbr.scoc.2.rdf -t 2
rdf2spy     jm8.990804.cbr.scoc.2.rdf   jm8.990804.cbr.scoc.2.spy 

ratioimg -1 jm8.990805.cbr.nrm.rdf -2 jm8.990805.cbr.nrm.sc.rdf -o jm8.990805.cbr.scoc.2.rdf -t 2
rdf2spy     jm8.990805.cbr.scoc.2.rdf   jm8.990805.cbr.scoc.2.spy 

ratioimg -1 jm8.990806.cbr.nrm.rdf -2 jm8.990806.cbr.nrm.sc.rdf -o jm8.990806.cbr.scoc.2.rdf -t 2
rdf2spy     jm8.990806.cbr.scoc.2.rdf   jm8.990806.cbr.scoc.2.spy 

ratioimg -1 jm8.990809.cbr.nrm.rdf -2 jm8.990809.cbr.nrm.sc.rdf -o jm8.990809.cbr.scoc.2.rdf -t 2
rdf2spy     jm8.990809.cbr.scoc.2.rdf   jm8.990809.cbr.scoc.2.spy 

Before I run this, though, I need to fix the vignetting from before--the output files 
will be about 3.5 Meg each otherwise.  --> Save that for tomorrow.

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

                        2000 January 18

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

My quick perusal of the Aug 1 ratio image made it clear that we need color 
instead of a grayscale: grayscales just don't do it.  I don't think that's
possible with Transform, but perhaps XV, GIMP, or IDL can do it.

The problem yesterday was that I had mixed up rows vs. columns.  

Here's the correct and renamed script:

# reason:/data/ast5/1999JM8/arecibo/proc/rng/jm8.ratio.proc
#
# Lance A. M. Benner
#
# Created: 2000 January 17
# Modified:2000 January 18
#
# Vignette the 1999 JM8 Arecibo OC and SC images to be 200 cols x 500 rows.
# and then output Spyglass Transform files.  Then use Keith's software
# ratioimg to produce SC/OC images in rdf and Spyglass formats.
#
# This script is designed to be run on think.jpl.nasa.gov
#
# comvin notation: 300 2000 150 1000 means 300 columns x 2000 rows 
# centered on column 150 and row 1000
#
# think:/public/protected/lance/1999JM8/arecibo < 77 > ratioimg -h
# Usage:  ratioimg -1 channel_1_file -2 channel_2_file -o output_ratio_file  -t threshold
#         Inputs should have same numbers of corresponding, normalized frames
# convention: file 1 = OC, file 2 = SC, t = threshold in sigmas
#
# -------------------------------------------------------------------------------

# August 1: 5-sigma threshold
comvin  jm8.990801.cbr.nrm.sc.rdf     jm8.990801.cbr.nrm.vig.sc.rdf  200 500 150 1000
comvin  jm8.990801.cbr.nrm.rdf        jm8.990801.cbr.nrm.vig.rdf     200 500 150 1000
rdf2spy jm8.990801.cbr.nrm.vig.sc.rdf jm8.990801.cbr.nrm.vig.sc.spy
rdf2spy jm8.990801.cbr.nrm.vig.rdf    jm8.990801.cbr.nrm.vig.spy
ratioimg -1 jm8.990801.cbr.nrm.vig.rdf -2 jm8.990801.cbr.nrm.vig.sc.rdf -o jm8.990801.scoc.5.rdf -t 5
rdf2spy     jm8.990801.scoc.5.rdf         jm8.990801.scoc.5.spy 

# August 2: 5-sigma threshold
comvin  jm8.990802.cbr.nrm.sc.rdf     jm8.990802.cbr.nrm.vig.sc.rdf  200 500 150 619
comvin  jm8.990802.cbr.nrm.rdf        jm8.990802.cbr.nrm.vig.rdf     200 500 150 619
rdf2spy jm8.990802.cbr.nrm.vig.sc.rdf jm8.990802.cbr.nrm.vig.sc.spy
rdf2spy jm8.990802.cbr.nrm.vig.rdf    jm8.990802.cbr.nrm.vig.spy
ratioimg -1 jm8.990802.cbr.nrm.vig.rdf -2 jm8.990802.cbr.nrm.vig.sc.rdf -o jm8.990802.scoc.5.rdf -t 5
rdf2spy     jm8.990802.scoc.5.rdf         jm8.990802.scoc.5.spy 

# August 3: 5-sigma threshold
comvin  jm8.990803.cbr.nrm.sc.rdf     jm8.990803.cbr.nrm.vig.sc.rdf  200 500 150 400
comvin  jm8.990803.cbr.nrm.rdf        jm8.990803.cbr.nrm.vig.rdf     200 500 150 400
rdf2spy jm8.990803.cbr.nrm.vig.sc.rdf jm8.990803.cbr.nrm.vig.sc.spy
rdf2spy jm8.990803.cbr.nrm.vig.rdf    jm8.990803.cbr.nrm.vig.spy
ratioimg -1 jm8.990803.cbr.nrm.vig.rdf -2 jm8.990803.cbr.nrm.vig.sc.rdf -o jm8.990803.scoc.5.rdf -t 5
rdf2spy     jm8.990803.scoc.5.rdf         jm8.990803.scoc.5.spy 

# August 4: 5-sigma threshold
comvin  jm8.990804.cbr.nrm.sc.rdf     jm8.990804.cbr.nrm.vig.sc.rdf  200 500 180 476
comvin  jm8.990804.cbr.nrm.rdf        jm8.990804.cbr.nrm.vig.rdf     200 500 180 476
rdf2spy jm8.990804.cbr.nrm.vig.sc.rdf jm8.990804.cbr.nrm.vig.sc.spy
rdf2spy jm8.990804.cbr.nrm.vig.rdf    jm8.990804.cbr.nrm.vig.spy
ratioimg -1 jm8.990804.cbr.nrm.vig.rdf -2 jm8.990804.cbr.nrm.vig.sc.rdf -o jm8.990804.scoc.5.rdf -t 5
rdf2spy     jm8.990804.scoc.5.rdf         jm8.990804.scoc.5.spy 

# August 5: 5-sigma threshold
comvin  jm8.990805.cbr.nrm.sc.rdf     jm8.990805.cbr.nrm.vig.sc.rdf  200 500 150 436
comvin  jm8.990805.cbr.nrm.rdf        jm8.990805.cbr.nrm.vig.rdf     200 500 150 436
rdf2spy jm8.990805.cbr.nrm.vig.sc.rdf jm8.990805.cbr.nrm.vig.sc.spy
rdf2spy jm8.990805.cbr.nrm.vig.rdf    jm8.990805.cbr.nrm.vig.spy
ratioimg -1 jm8.990805.cbr.nrm.vig.rdf -2 jm8.990805.cbr.nrm.vig.sc.rdf -o jm8.990805.scoc.5.rdf -t 5
rdf2spy     jm8.990805.scoc.5.rdf         jm8.990805.scoc.5.spy 

# August 6: 5-sigma threshold
comvin  jm8.990806.cbr.nrm.sc.rdf     jm8.990806.cbr.nrm.vig.sc.rdf  200 500 180 372
comvin  jm8.990806.cbr.nrm.rdf        jm8.990806.cbr.nrm.vig.rdf     200 500 180 372
rdf2spy jm8.990806.cbr.nrm.vig.sc.rdf jm8.990806.cbr.nrm.vig.sc.spy
rdf2spy jm8.990806.cbr.nrm.vig.rdf    jm8.990806.cbr.nrm.vig.spy
ratioimg -1 jm8.990806.cbr.nrm.vig.rdf -2 jm8.990806.cbr.nrm.vig.sc.rdf -o jm8.990806.scoc.5.rdf -t 5
rdf2spy     jm8.990806.scoc.5.rdf         jm8.990806.scoc.5.spy 

# August 9: 5-sigma threshold
comvin  jm8.990809.cbr.nrm.sc.rdf     jm8.990809.cbr.nrm.vig.sc.rdf  200 500 164 414
comvin  jm8.990809.cbr.nrm.rdf        jm8.990809.cbr.nrm.vig.rdf     200 500 164 414
rdf2spy jm8.990809.cbr.nrm.vig.sc.rdf jm8.990809.cbr.nrm.vig.sc.spy
rdf2spy jm8.990809.cbr.nrm.vig.rdf    jm8.990809.cbr.nrm.vig.spy
ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.5.rdf -t 5
rdf2spy     jm8.990809.scoc.5.rdf         jm8.990809.scoc.5.spy 

# -- END --

think:/public/protected/lance/1999JM8/arecibo < 91 > source jm8.ratio.proc
Comvin using 150.000000,1000.000000 as center
Comvin using 150.000000,1000.000000 as center
Comvin using 150.000000,619.000000 as center
Comvin using 150.000000,619.000000 as center
Comvin using 150.000000,400.000000 as center
Comvin using 150.000000,400.000000 as center
Comvin using 180.000000,476.000000 as center
Comvin using 180.000000,476.000000 as center
Comvin using 150.000000,436.000000 as center
Comvin using 150.000000,436.000000 as center
Comvin using 180.000000,372.000000 as center
Comvin using 180.000000,372.000000 as center
Comvin using 164.000000,414.000000 as center
Comvin using 164.000000,414.000000 as center

Do this again with a 10-sigma threshold (recall that Keith used
5 and 10 sigma with the 1996 Toutatis data).

I used the existing vignetted SC and OC files to create new ratio
images with a 10-sigma threshold:

# August 1
ratioimg -1 jm8.990801.cbr.nrm.vig.rdf -2 jm8.990801.cbr.nrm.vig.sc.rdf -o jm8.990801.scoc.10.rdf -t 10
rdf2spy     jm8.990801.scoc.10.rdf        jm8.990801.scoc.10.spy 

# August 2
ratioimg -1 jm8.990802.cbr.nrm.vig.rdf -2 jm8.990802.cbr.nrm.vig.sc.rdf -o jm8.990802.scoc.10.rdf -t 10
rdf2spy     jm8.990802.scoc.10.rdf        jm8.990802.scoc.10.spy 

# August 3
ratioimg -1 jm8.990803.cbr.nrm.vig.rdf -2 jm8.990803.cbr.nrm.vig.sc.rdf -o jm8.990803.scoc.10.rdf -t 10
rdf2spy     jm8.990803.scoc.10.rdf        jm8.990803.scoc.10.spy 

# August 4
ratioimg -1 jm8.990804.cbr.nrm.vig.rdf -2 jm8.990804.cbr.nrm.vig.sc.rdf -o jm8.990804.scoc.10.rdf -t 10
rdf2spy     jm8.990804.scoc.10.rdf        jm8.990804.scoc.10.spy 

# August 5
ratioimg -1 jm8.990805.cbr.nrm.vig.rdf -2 jm8.990805.cbr.nrm.vig.sc.rdf -o jm8.990805.scoc.10.rdf -t 10
rdf2spy     jm8.990805.scoc.10.rdf        jm8.990805.scoc.10.spy 

# August 6
ratioimg -1 jm8.990806.cbr.nrm.vig.rdf -2 jm8.990806.cbr.nrm.vig.sc.rdf -o jm8.990806.scoc.10.rdf -t 10
rdf2spy     jm8.990806.scoc.10.rdf        jm8.990806.scoc.10.spy 

# August 9
ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.10.rdf -t 10
rdf2spy     jm8.990809.scoc.10.rdf        jm8.990809.scoc.10.spy 

I copied this and other jm8 Arecibo scripts to reason:/home/lance/src/

I organized the results into this directory structure:

reason:/data/ast5/1999JM8/arecibo/proc/rng/ratio_images < 58 > ls
10_sigma_threshold/   5_sigma_threshold/    vignetted_oc_images/  vignetted_sc_images/

Look at the results
-------------------

How did Keith add color to the Toutatis ratio images?  I've poked around with 
Spyglass Transform and found that one can select from grayscale or colors under
the "Tables" menu.  Selecting "hot metal" reproduced the 5-sigma color bar that
Keith used.  It's necessary to use an external program (like XV, GIMP, or IDL) to
get logarithmic stretches.  Steve mentioned that he and Keith had a hard time
finding a stretch that they liked--there wasn't enough dynamic range.

I need to redo the August 9 ratio image--it's truncated.  The other images are OK.

The big surprise is that the ratio seems quite high--close to 0.5.  We didn't do
much cw at Arecibo but we did do some, so I need to check it out.  The high 
ratio worries me--perhaps there's some system problem that's skewing the ratio?
How thoroughly have both channels been tested?  Has it been calibrated against
targets that are well understood, like Mercury?  0.5 is significantly higher than
the ratio at X-band from the Goldstone CW data, which were close to 0.2.  

The answer appears to have been that the saturation I chose (0.8) was such that
the overall ratio appeared close to 0.5.  When I set the saturation level at 0.5,
then the average ratio changed to about 0.3, which is conceivable.  

At any rate, quick inspection of the Aug 1 and 5 images shows an obvious decrease
in SC/OC on portions of the LE and scattered brighter pixels toward the limb.  The
distribution of darker pixels isn't uniform along the LE, though: in the Aug 5 
image they concentrate in two regions on either side of 0 Hz, although the LE 
in general is darker than elsewhere.  In the Aug 1 image, there are scattered
regions with darker pixels.  

Overall, though, the surface is more heterogeneous than the surface of Toutatis, 
which is an important rsult.  In the more detailed paper (not the Science paper) 
we should repeat the Toutatis discussion.  

The "Saturn" table with a saturation of 0.3 or 0.5 looks pretty good--certainly
better than the "Hot metal" table: there's *a lot* more dynamic range and the 
zero-sigma points map to white, which will save toner.  A bit more experimenting
shows that a saturation of 0.4 is probably a very good compromise.  The darkest
LE pixels have ratios of close to or somewhat less than 0.1 but the overall 
ratio is between 0.2 and 0.3, consistent with the Goldstone results.  The darkest
points are darker than the ones seen in 1996 Goldstone images of Toutatis--those
ratio images show a more uniform surface with only subtle ratio effects.  Of
course, the JM8 data are better, but it could be that the surface scattering is
different.

Our Lexmark color printer "monet" can make hardcopies directly from Spyglass
Transform--just enter the printer name and select color (vs. grayscale) prints.

Be aware that the toner on the paper tends to smear.  We'll need to use a better
printer for the camera-ready figures.

I labelled the Aug 5 image and saved the settings in a Spyglass macro.

Clearly we need to take SC images for very high SNR Goldstone targets in the 
future and for any well-resolved target with a high SC/OC.  What would an 
Adonis SC/OC image look like?

An idea to keep in mind: explore the saturation for each day's image--0.4 looks
great for Aug 5, but it might not for other days.

The Aug 2 image is really cool: the radar-facing side of the big crater near the
middle of the image (not the big concavity, obviously) has a region of very low
SC/OC that is even more pronounced than that at the closest part of the LE.

Ah, the thrill of scientific discovery!  This is fun...

The Aug 4 image doesn't show much--there were only 5 looks.

Similarly with the Aug 6 image-- there are only 13 looks.  That's enough to see
darker pixels on the LE.

Redo the Aug 9 image
--------------------

For some reason I set the mid col at 164 instead of 200 (image is 400 cols wide).
This should be straightforward...  I'm repeating the vignetting of the OC and SC
images, creation of the OC and SC Spyglass files, and creation of the ratio rdf
and Spyglass files.  The image is still on the right edge but none of it is 
truncated.  

In general, the images from Aug 4, 6, and 9 don't show much detail due to small
numbers of looks (Aug 4 and 6) and weaker SNR (Aug 9).  The other images are
very interesting.  This is all for a 5-sigma threshold.

Summary
-------
There are distinct SC/OC variations on the surface on all the days (Aug 1, 2, 3, 
and 5) when there's enough SNR to discern it at locations other than the LE.  The 
lowest SC/OC values concentrate at the LE and are typically about 0.1 or somewhat
less.  The strongest pixels are on the limb.  Sides of craters that are probably
oriented close to orthogonal to the radar also have low ratios.  

We could also repeat the more extensive analysis in Ostro et al. (1999), who used
the ratios to constrain the abundance of rocks on the surface of Toutatis.  
Their discussion is rather complicated but we should be able to condense it and
apply it to 1999 JM8 once we have the 3-D shape models, radar scattering law,
and radar albedos.

Steve pointed out that the large low SC/OC region in the Aug 2 image is the first
real ratio feature seen on any asteroid.  We compared SC and OC images and images
showing the same feature on Aug 9.  Steve points out that there could be a 
lack of small-scale structure there or that the radar scattering law there could
be different.  He favors the former explanation.  I thought that we could be seeing
nearly specular reflections from a crater wall oriented nearly orthogonal to 
the radar line of sight, but Steve thinks it could be more substantial.  

This is really a question for Scott, so I'm going to do a screen grab on the
images, post them on a website, and as Scott what he thinks.  This may also help
get Scott moving on the shape reconstruction.

Let's go the whole way: put SC, OC, and SC/OC images on the web for each 
day of Arecibo data.  

>> Tell Scott where the SC images are <<

The Aug 2 image alone justifies obtaining ratio images with future experiments.

Steve points out that we should use Keith's program "trace" on JM8 to see where
features are on the surface.  

Aug 9 SC/OC image
-----------------
I also need to redo the Aug 9 vignetting etc. again--the edge of the echo
is cut off.  Move the image over another 30 Doppler bins.  

# August 9: 5-sigma threshold
comvin  jm8.990809.cbr.nrm.sc.rdf     jm8.990809.cbr.nrm.vig.sc.rdf  200 500 230 414
comvin  jm8.990809.cbr.nrm.rdf        jm8.990809.cbr.nrm.vig.rdf     200 500 230 414
rdf2spy jm8.990809.cbr.nrm.vig.sc.rdf jm8.990809.cbr.nrm.vig.sc.spy
rdf2spy jm8.990809.cbr.nrm.vig.rdf    jm8.990809.cbr.nrm.vig.spy
ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.5.rdf -t 5
rdf2spy     jm8.990809.scoc.5.rdf         jm8.990809.scoc.5.spy 

10-sigma:
# August 9
ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.10.rdf -t 10
rdf2spy     jm8.990809.scoc.10.rdf        jm8.990809.scoc.10.spy

...done

This version is clearly better.  Let's re-create the spiffy ratio image
and then leave: it's almost 19:30.  

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

                        2000 January 19 & 20

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

Close inspection of the ratio images shows some pixels close to the LE
at freqs separated from the echoes by a few Doppler bins.  Those are seen
in the strongest images when we had what I suspect are (sincx)^2 effects.

Yesterday I used a stretch of 0.4.  After tinkering with the images using
Spyglass Transform, saturation = 0.5 shows more detail and works better; 
0.6 is too far--pixels near the LE are too uniform.  Let's experiment with
logarithmic stretches too using XV.  ==> Not so great.  That introduced 
more distortion than clarity.  The intrinsic dynamic range of the pixels
that we care about seems better suited to a linear stretch.

I printed each plot with sc/oc saturated at 0.5.  I posted them on a
website.

Let's explore the high end of the SC/OC distribution in the Aug 2 image.
There are several hundred points with mu > 0.6, most of them at the more
distal regions.  One interesting juxtaposition occurs immediately adjacent
to the low SC/OC feature on what appears to be the side of a crater.  My 
preliminary explanation is that there could be a relative increase in 
roughness at the top of the crater, which is effectively on the horizon.

Date   Min  Max
----   ---  ---
Aug 1  
Aug 2  0    1.26
Aug 3  
Aug 4  
Aug 5  
Aug 6  
Aug 9  

Thus far I haven't looked at the 10-sigma results.  To be complete, I should
also check a weaker threshold, say, 2- or 3-sigma.  Obviously chi-sq and
self noise will be more of an issue, especially with the Aug 4 and 6 data.

Steve and I discussed the ratio images in more detail.  The precedents for 
sc/oc features are lunar work by Tommy Thompson, Nick Stacy, and Jean-Luc 
Margot, and Magellan.  Thompson's work long ago demonstrated that X-band
radar can be sensitive to ejecta blankets that aren't obvious optically.

A major issue is the noise estimates in the ratios.  The noise obeys a 
chi-square distribution.  Stacy et al. discuss uncertainty estimates.  
They adopt an F-distribution formulation, in which the fractional uncertainty
for N looks is approximately sqrt(2/N).  
              
Date   Looks   sqrt(2/N)
----   -----   ---------
Aug 1   26      0.28
    2   28      0.27
    3   31      0.25
    4    5      0.63 <== TILT
    5   35      0.24
    6   13      0.39 <== not so great
    9   25      0.28 

Aug 4 and 6 don't have enough looks to be useful.  Concentrate on the
other days. 

Steve points out that another way around the fractional errors is to 
work with many pixels that define a feature.  There are about 100 pixels
in the low sc/oc region, so we could run a boxcar filter over them
to compute sc/oc and the uncertainties.  For that many pixels,
the distribution is Gaussian.  Then pick adjacent regions with strong
echo power and do the same.  There is just such a region at about the
same range gates as the low sc/oc feature but at slightly more positive
Doppler frequencies.  There should be a strong sc/oc contrast between
the regions.  Other adjacent regions aren't as easy to define due to 
radar shadowing at larger ranges and more shadowing at lesser ranges in 
a crater.  We can also compare another region at more negative Doppler
frequencies, also at about the same ranges (although that region has fewer
bright pixels.   

10-sigma threshold data 
-----------------------
The low sc/oc feature on Aug 2 is obvious in the 10-sigma data too.  The
linear features and somewhat smaller ranges are more evident.  I cranked out 
the ratio images.

3-sigma threshold results
-------------------------
I also computed three-sigma ratio images on think.  I transferred the
results to reason.  The results are about as would be expected: more
pixels show up at the more distal regions and deeper into features that
look like craters.  There are a few scattered noise pixels and more 
(sincx)^2 pixels.  Otherwise there aren't any new features.  
==> Don't bother going to lower thresholds than this.

Let's use the 3-sigma data to constrain the sc/oc contrast adjacent to
the feature in the Aug 2 image.  It helps to enlarge the image to 1000x1000

Low SC/OC feature:
Use rows 172-181 and cols 122-131 (10 x 10).
col  sum
---  ---
122  0.92
123  1.05
124  0.93
125  0.79
126  0.81
127  0.67
128  0.75
129  0.71
130  0.78
131  0.94
Sum  8.35  mean = 0.0835 

Adjacent higher SC/OC feature:
Use rows 172-181, cols 132-141 (10 x 10)
col  sum
---  ---
132  1.20
133  1.53
134  2.32
135  2.58
136  2.46
137  2.48
138  2.59
139  2.60
140  3.41
141  2.95
Sum  24.12 mean = 0.24  About a factor of 3 larger.

There are 2800 looks in each region for a fractional error of sqrt(2/2800) = 0.03,
so the difference is statistically significant.  One could already conclude this
by inspection, but now we have a quantitative result to back it up.

Stacy et al. (1997) note that the strongest radar backscatter from the lunar poles
occurs on the sides of craters oriented toward the radar.  They obtained a range
of sc/oc from crater rims, ranging from high (close to unity) to moderate (close to
about 0.2-0.4), but in their Fig. 2B I don't see any crater *rims* with sc/oc obviously
close to 0.1 or less.  Granted, they're looking at a much larger object with a
thick regolith and with facets that are much larger. 

Careful inspection of the sc/oc and oc images shows a radar-bright "bump" inside
the crater-like structure.  I've already noticed that feature in the Aug 9 image, 
but it's now apparent that it's present on Aug 2 and even in images obtained on
Aug 1.  My thinking before was that the bump was on the hemisphere opposite the
large crater.  The images suggest that the low sc/oc region is on the bump, not
on the crater wall.  Perhaps the radar-facing side of the bump is scattering 
in a manner similar to the LE.  

Alternatively...could there be a slump on the side of the crater?  There *is* a
lack of echo power between the bright "bump" and the crater wall.  

The resolution of the Aug 1 image isn't high enough to see details on the "bump,"
but there's clearly a cluster of bright OC pixels at the right spot.

The "bump" is not evident on Aug 3, although structures that may be craters
of ~200 and ~500 m in diameter are present on that day.

What I don't see are sc/oc features on Aug 1 and 9 at the location of the "bump."
The Aug 1 image is strong enough but there's no distinct pattern of low sc/oc.
The Aug 9 image isn't strong enough in terms of S/N.

==> We need the shape model.  The gravitational slopes are also relevant.  

Other things to look for: long ~linear features such as ridges and grooves.
No grooves have been seen yet among radar-detected NEAs.

- - - - - - - - - - 

As the website images are now, there's a lot
of wasted space, so let's vignette the files more.  For now, vignette by 
rows and columns.  Ultimately we'll vignette so the images have the same
dimensions (we don't know the km/Hz conversion yet).

As I've chosen them, the numbers of rows and columns will be uneven.  The goal is
to save screen space.

<< Stay tuned >>

Generate labelled SC and OC Arecibo images
------------------------------------------

I haven't produced really nice images from each day yet for the Arecibo
data, so let's do it for each polarization.

I started to make a nice version of the Aug 2 OC image.  Finish it tomorrow.
It will be necessary to do logarithmic stretches due to the dynamic range
of the OC images. 

==> I used a template to create the images, but I haven't played with the
logarithmic stretches yet.  It's time to get some of this down into a 
draft manuscript.

1. 10-sigma data ==> DONE
2. SC and OC images with linear and logarithmic stretches ... in progress
3. Better vignetting of the ratio images...some other time
4. boxcar filter the Aug 2 image ==> DONE for the regions of interest
5. 3-sigma ratio images ==> DONE

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

                        2000 January 21

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

Directly compare the Arecibo SC and OC images
=============================================

August 1
--------
Obviously the images are similar but the OC image is much brighter and it
shows more detail in regions where there is none in the SC image.  The
"bump" doesn't stand out in the SC image but it does in OC.  Some of the
distal pixels on the arcuate feature on the negative limb are barely 
discernible in SC but are obvious in OC.  Likewise, there are a few relatively
bright OC pixels on the positive distal limb that do not appear in SC.

August 2
--------
The principal differenences are between the "bump" and the distal echoes
that barely show up in the SC image but are obvious in the OC image.  By
"distal" I refer to the weak points along the limb and TE at negative
freqs.  There appear to be two impact craters there in the OC image but they
aren't evident in the SC image.  The craters are about 350 and 400 m in 
diameter.  

August 3
--------
Something I hadn't noticed before is that the big central concavity is 
evident in the Aug 3 images, as is one of the elliptical craters that
was obvious on Aug 2.  There's a feature in the OC image that looks like
a crater rim, but it's not visible in the SC image.  There are several
linear OC features on the negative TE that aren't present in the SC
image.  These are mostly curved collections of relatively bright pixels 
that look like obliquely-viewed craters.  The crater mentioned above on
Aug 3 and an adjacent feature that may be another crater (both in the OC image) 
are close to a bent lineament of bright pixels that is clear in the Aug. 4
and 5 images.  The crater-like features are present in the Aug 4 image,
but they're subtle due to low SNR.

August 4
--------
The ridge-like feature I mentioned for Aug 3 isn't obvious in the SC image,
nor are any of the features that look like craters.  There isn't enough S/N.
The far negative TE seems even weaker in SC than the overall S/N of the image
would suggest, but given that there are only 5 looks, I'm not going to 
dwell on it.

August 5
--------
The images look similar except for S/N differences, which prevent some OC
features from being seen in the SC image.  The OC image is so strong that
it reveals numerous small (~200 m) impact craters.  Some larger craters
are also apparent in SC.  Some of the OC craters appear to be only about
~100 m in diameter.

August 6
--------
thus far I've just been comparing the images by inspection by fiddling
with the saturations.  To improve the results, I should set the the
lower thresholds to, say, 3-sigma.  

There are only 13 looks so the SC image doesn't have much high-freq
detail--mostly it just shows the outline of the shape.  The OC image
shows numerous craters.

In a sense, the SC images are reminiscent of the Goldstone images in
terms of the levels of detail that are visible.

August 9
--------
These are the weakest Arecibo images, and as such, the SC image doesn't
reveal much detail.  The "bump" is present in both polarizations as are
a few features that are probably large craters. 

- - - - - - - - - - 

Keith called about the format of Goldstone SC and OC dual-polarization 
imaging.  Evidently Ray never settled on a format and the separation is
ugly, so there's no packaged software available for a quick reduction.
Keith separated the 1996 Toutatis data by hand.  We could ask Marty/Ray
about the present format, but ultimately we should match whatever
Arecibo does with Jean-Luc's GSB (does that match the radar interface?).

If Jean-Luc installs one of his boxes at Goldstone, then that would 
obviously facilitate getting uniform data formats.  

With the present Goldstone system, the problem is separating the SC and
OC images in near-real time so we can see what we have in the data.
Had we taken dual poln imaging last summer with JM8, we would have had
to have bugged Keith to reduce it, which could have interfered with
the decisions we had with the observing strategy on each day.

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

                        2000 January 24 & 25

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

I printed out well-labeled GSB images in both polarizations from each day.
It turns out that I made a mistake with my earlier attribution of the "bump"
seen so clearly on Aug 2 in the Aug 1 image: I was looking at the wrong 
crater in the Aug 1 image--the one in the center on Aug 1 does have a 
group of bright pixels just inside the trailing crater rim (i.e. away from 
the LE) but that's not the crater I focussed on in the Aug 2 images.
The correct crater in the Aug 1 image (the more tear-drop shaped one
in the delay-Doppler images) also has a collection of brighter pixels, 
but they don't have a distinct morphology in the Aug 1 image.

It turns out that I never saved some of the Goldstone spyglass files as
images--several are only arrays of numbers.  Rats...

Closer inspection of the July 24 Goldstone image shows more (sincx)^2 effects.
There's a bright spot in the large nearly central crater just to the positive
side of zero Hz--the same spot where one is visible in Aug 1 Arecibo images.

The July 23 image shows hints of the big concavity that is much more evident
in early August.  

- - - - - - - - - - 

Impact Cratering on 1999 JM8
----------------------------
1.  Geographic distribution of craters: is it random?

2.  R-plot: is the surface saturated?  If we assume that the population of 
    impactors is the same as for Ida, Gaspra, and Mathilde, what can we say 
    about the age of 1999 JM8?  

3.  depth/diameter ratios: are the uncertainties in the dimensions small 
    enough for meaningful statements?  Based on small lunar craters, we should
    expect ratios close to about 0.2.  But will large craters that are a  
    significant fraction of the asteroid's diameter obey this simple relationship?
    The smallest craters are impacting into a half-space, but the larger ones are
    not.  Do Asphaug et al. (1996) say anything about this?

4.  Is there evidence of craters overlapping adjacent craters?  Any evidence for
    ejecta?  

No obvious ejecta in the images except for the radar-bright annulus surrounding what
appears to be a ~100-m crater in the July 28 image.  No obvious rays.

The craters appear to be simple in structure, although the delay-Doppler 
projection makes several likely craters appear tear-shaped.  The large
central concavity may be somewhat angular in map view, perhaps due in part to its
large size relative to that of 1999 JM8.  

Raised rims?  There are hints in terms of radar bright features that appear 
along the rims and closer to the LE than the distal rims.  

Note: depth/diameter ratios have been estimated for Gaspra, Ida, and Mathilde.
Gaspra and Ida have d/D ~ 1/6.5 - 1/7.  There's significant dispersion in the
ratio for Mathilde: 0.12-0.25 (there are fewer well-imaged craters on Mathilde).
Why is d/D apparently lower for small objects (including Deimos, but excluding 
Phobos) than for, say, the Moon?  Sullivan et al. (1996, Ida) and Carr et al. 
(1994, Gaspra) address this issue and claim that the best explanation is that
the low gravity provides less ejecta to pile up and raise the rim heights.  
That seems overly simplistic and begs for someone like Asphaug to examine this
in detail.  Asphaug et al. (1996) did examine bright annuli surrounding craters
but not rim heights.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

SC/OC > 0.8 in the rato images
------------------------------

Aug 1: isolated pixels mostly along the TE.  There are also small numbers inside
       the large rounded features that are probably impact craters.

Aug 2: visual inspection suggests there are less than on Aug 1.  They again concentrate
       among the weaker SNR pixels near the TE.  There are a few in the ellipsoid
       crater-like feature on the approaching limb. 

Aug 3: Very few among craters (aren't many craters visible); small numbers of high
       SC/OC among weak TE pixels.  Also a few along the limbs, as also seen on the
       other days.  Some of those may be (sincx)^2 effects because a number are not
       contiguous with the echoes.

Aug 5: High sc/oc pixels are again dispersed among the distal regions, which extend
       over larger ranges on Aug 5 than on other days due to the greater range 
       extent of the image.  Overall there are also more such pixels than on the
       other three days.

- - - - - - - - - - - - - - -  - - - - - - - - - - - - - - - 

Detailed summary of delay-Doppler images from July 21-August 9
==============================================================

JULY 20: 
Spatially resolve target.  Maximum range extent is given by 
Table DISC-INTEGRATE PROPERTIES.  No features visible; crude indication
of angularity of the shape with a pointed end oriented toward the radar.

JULY 21. 
Resolved JM8 into ~a few hundred pixels.  See pointed end oriented
toward negative frequencies.  Much stronger image due to closer target
and much longer integration.  Starting to see possible surface features
(large concavities?) near the TE.

JULY 23: 
Asymmetric delay-Doppler distribution.  Brightest pixels are on the
negative limb.  Distal group of weak pixels at the negative TE show the first
hints of a significant concavity.  Best resolution to date: 75 m x 0.075 Hz.

JULY 24: 
Spheroidal echo signature along the LE but interesting detail 
within the interior of the echo: two prominent tear-drop shaped structures
that lack echo power.  First image with obvious structure within the echo.
Much stronger evidence for a big concavity along the TE.  Hint of weak 
echoes from a distal feature along the negative limb.  Appearance of the 
echoes has not yet repeated from earlier days.  First set of images long enough
to check for evidence of rotation: none seen.  Tear-shaped features may
be obliquely-viewed impact craters.  Placed hundreds of pixels on the 
asteroid.

JULY 27: 
Increased resolution to 37.5 m x 0.05 Hz.  Placed thousands of 
pixels on the asteroid.  Clearly reveal an asymmetric shape with a promient
pointed end slightly positive of zero Hz.  Asteroid from this perspective
is very angular.  Pointed end vaguely resembles appearance of echoes on 
July 20 but detailed comparison is not possible because echoes on July 20 
were much weaker and much coarser resolution.  Hints of detail within the
echo beyond the LE but less than was seen on July 24.  Echo isn't strong 
enough due to short interval covered (only about 1 hour).

JULY 28: 
Image is dramatically different from
the July 27 image.  Distribution of echo power is asymmetric with more power
evident at negative frequencies than at positive frequencies.  LE has two
prominent "hills" with sub-Earth points that are at nearly the same 
time delay.  Between the two hills the LE is about 10 0.25 us range gates
back.  That is, the LE is undulatory in time delay.  There's a
a radar-bright annulus near zero-Hz that encompasses a group of radar-dark
pixels that are about 100 m in diameter, suggesting a small impact crater 
with a radar-bright feature surrounding it.  This resembles some impact
craters seen in radar observations of the Moon and Venus and may indicate
a relatively young crater with a rough surrounding near-surface at 
decimeter spatial scales, probably due to the impact.  We do not expect 
significant regolith retention on such a small object, so the radar bright
annulus may be the result of proximal surface shaking, as Asphaug et al.
(1996) proposed for optical annuli surrounding craters on 243 Ida.  There 
is also an arcuate feature of bright pixels just inside the positive limb.  

JULY 31: 
This and the August 1 image are the highest resolution images
obtained at Goldstone.  The image does not obviously repeat features that
were seen on previous days.  The shape of the LE is somewhat angular but
there are no pointed ends or twin peaks visible as there were on July 27
and 28.  New surface features are visible at ranges beyond the LE.  For 
example, at frequencies just positive of zero Hz and beginning about 20
range gates in from the LE there's a large approximately circular feature
that is probabably an impact crater.  Its range extent is about 700 meters 
and its bandwidth is about 0.9 Hz.  Adjacent to this crater at slightly
larger range gates is another much smaller, nearly circular feature that
may also be an impact crater that extends about 190 m in range and 0.3 Hz
in Doppler frequency.  At the same range gates as this crater-like feature
but at immediately more positive Doppler frequencies is a small radar-
bright region spanning about 0.2 Hz and about 90 meters.  The resolution
is not high enough to determine definitively what this feature is.

A third possible crater that has range and Doppler extents of about 400 m 
x 0.5 Hz is present adjacent to but at larger time delays than the bright
feature.  There is a weak roughly circular feature near the TE along
the positive limb that may be another crater; it appears to be close to 
1 km in range extent and about 0.9 Hz in Doppler frequency.  

The TE near zero Hz is has a broad distribution of weak pixels that 
suggest a large concavity.  The other prominent feature in this image is 
a linear group of bright pixels between the positive limb/LE and the
large crater that starts about 20 range gates behind the LE.

The LE negative of zero Hz is almost linear--that is, it's not parabolic
as would be expected from a spherical target.  

AUGUST 1: 
---------
This is the only day in which we have coverage at both Goldstone
and Arecibo.  The Arecibo image is much stronger, has higher range and
frequency resolution, and shows more detail.  Comparison of the Goldstone
and Arecibo images indicates that there are no features in the Goldstone
image that are not also present in the Arecibo image.  

This image is similar to the one obtained on July 24, suggesting that
at least one component of 1999 JM8's rotation period is close to 8 days.
(This does not include effects of rotation due to sky motion).  The two
large crater-like features seen on July 31 are obvious on August 1 and
also correspond to the two tear-shaped features seen on July 24.  One
feature is clearly an impact crater with an apparently radar bright rim
near the LE.  This suggests either elevated topograph, surface roughness,
or both along that rim.  There is a narrow region of bright pixels
extending from the crater rim just negative of zero Hz toward the 
positive LE/limb and in the other direction toward the negative
limb.  Within the large crater just negative of zero Hz there is a 
group of radar bright pixels at ranges just inside (i.e.
closer to the radar) than the far rim.  The really obvious crater
on the negative side of zero Hz has a range extent of about 850 m
in the Arecibo image (using bright pixels along apparent proximal
and distal rims) and about 880 m in the Goldstone image.  

There is a prominent tear-shaped feature along the positive limb that may
be a crater viewed obliquely.  It has a radar-bright rim and there is a 
diffuse group of bright pixels about 10 range gates deep and about 
8 Doppler cells wide adjacent to it on its side toward the LE.  The range
extent is indefinite due to the non-circular shape but it appear to be
either 1.0 or 1.2 km, depending on which group of bright pixels one
chooses to define the distal rim.  

The receding limb is strikingly angular with a sharp bend 
about 3 km beyond the LE at the subradar point.  Between the sub-Earth 
point and the bend, much of the receding limb is approximately linear as
a function of delay and Doppler, and appears to correspond to the
linear LE that was seen at negative frequencies on July 31.  

There is a column of faint but statistically significant pixels at 
the receding limb that extend at least ~1 km deeper in range than the 
rest of the TE.  The column is about 0.2 Hz wide.  

The TE is irregular in shape and it suggests the presence of a large 
concavity; the shape of the concavity is not obvious but it does not 
appear to be not circular.

AUGUST 2:
---------
The perimeter of the August 2 image is strikingly rounded with about 3/4
of a circular perimeter visible.  The most prominent interior feature 
in the echo is a large radar dark region that extends from the TE inward 
to slightly less than 1/2 of the echo's delay
depth.  The large dark feature appears to be a substantial concavity that is
about 2.4 km wide.  

Two prominent tear-shaped features are probably the craters that were 
seen on August 1, but they are rotated by about 45 degrees relative to 
their position on the previous day.  The one near zero Hz has an intriguing
radar bright feature that appears inside it near the distal crater rim.
This feature may be a topographic high, but it is not clear whether it is
actually inside the crater or whether it is a superposition from the 
opposite hemisphere.  The rim of this crater closest to the LE is 
radar bright, as was seen with the rim of the other crater (that is near
the receding limb on Aug 2) that was near zero Hz in the Aug 1 image.
The central crater in this image has an apparent range extent of about 800 m.

The arc of points on the receding limb near the TE has an irregular
distribution of bright and dark pixels suggesting surface structure.

AUGUST 3:
---------
The echo is rounded and modestly asymmetric as a function of Doppler
frequency with points closer to the radar to the negative of zero Hz.

The August 3 image has an angular region at the TE that is devoid of
pixels with significant echo power, suggesting that it is the 
concavity seen in the August 2 image.  

The progression of tear-shaped crater from August 2 is obvious in
the August 3 image. The crater near zero Hz on August 2 is close to 
the receding limb on August 3.  The rim nearest the LE is again radar
bright, particularly at less negative Doppler frequencies.  The 
tear-shaped structure appears to have a maximum range extent of 
about 1.2 km, comparable to its extent on August 1 but about
50% more than its extent on August 2.  

There is another probable impact crater with dimensions of about 
560 m x 0.75 Hz that is evident on the negative side of zero Hz near
the sub-Earth point.  Its proximal rim begins about 150 m into the 
echo from the LE.  

A prominent radar bright, narrow linear feature extends from the 
positive limb toward the LE at zero Hz.  

There are hints of structure on the approaching limb and TE but the
echoes there are not strong enough to distinguish the features.

AUGUST 4:
---------
The August 4 image is distinctly asymmetric with the LE to the negative
of zero Hz.  The delay-Doppler distribution is broadly triangular.
The image has only 5 looks and the SNR relatively weak so that fewer 
surface details are visible than on other days.  The approaching limb
has three distinct linear segments, two of which are approximately
parallel.  There is a short segment between the two parallel
segments.  

The approximately linear radar-bright feature seen on August 3 (between
the approaching limb and the sub-radar point) is more obvious on August
4, although it has rotated by close to 50 degrees.  

There are hints of several circular features but none has sufficient
detail to be confident that it is an impact crater.  The best plausible
crater candidate is just inside the bend in the approaching limb and at
range gates just beyond the linear radar bright feature mentioned above.

AUGUST 5:
---------
The LE of this echo is the most nearly uniform in time delay of any 
day that we observed 1999 JM8.  The LE is not remotely parabolic, as 
would be expected of a spheroidal target, but is approximately flat.
The image is very strong and shows the most detail of any Arecibo 
image of this object.  Numerous approximately circular patches of
pixels dot the surface and are probably impact craters.  The two largest
craters are just past the LE near zero Hz and about half-way between
zero Hz and the receding limb.  They have dimensions of about 470 m x 0.14 Hz
and 450 m x 0.17 Hz.  There is another smaller crater-like feature
near the positive limb about half way between the LE and the TE
that has dimensions of about 420 m x 0.11 Hz. 
A fourth comparably-sized feature exists slightly closer to the TE
and near the receding limb.  

The August 5 image gives the impression that the portion of the surface
illuminated is heavily cratered.  Clearly more features that appear to
be impact craters are visible.  

The linear feature seen on the previous two days is evident close to the
receding limb but it isn't as prominent as it was on August 4.  

There is an indentation in Doppler frequency on the approaching limb.  
Pixels on the trailing edge at this feature are radar bright, suggesting
that surface facets have more projected area oriented normal to the line
of sight than is present on adjacent regions.  

The brightest pixels are on the positive side of the approaching LE.

AUGUST 6:
---------
The nearly flat surface that formed the LE in the August 5 image forms
the receding limb on August 6.  The echo is asymmetric and angular and
there are more pixels at positive frequencies than at negative frequencies.
The brightest pixels are on an approximately flat region positive of
zero Hz. Numerous dark circular features 
 are present and are probably impact craters.  Fewer are visible
in the August 6 image, which has only about 1/3 the number of looks
relative to the August 5 image.  The craters appear to be up to several
hundred meters in diameter. 

AUGUST 7:
---------
We resumed observing at Goldstone for two days.  The echoes have an
asymmetric delay-Doppler distribution.  The echo is more rounded than
on the previous three days. There is a radar-bright "step" on the 
negative limb that is the rotated "indentation" that was seen on the approaching
limb on August 5.  The image does not show any obvious detail inside
the echo other than an arcuate collection of pixels at the positive
limb.  
 

AUGUST 8:
---------
The delay-Doppler distribution of echo power illustrates that this side
of 1999 JM8 is approximately spheroidal, in stark contrast with the 
distribution seen between August 4 and 6.
The August 8 images span more than 7 hours and show the most compelling
evidence of rotation among any of the 1999 JM8 images.  However, the 
rotation is subtle.  In general the image is similar to the August 1 image:
the two prominent craters close to 1 km in diameter are both obvious, with
what appears to be a smaller crater between them, although there is some
rotation between the Aug 1 and 8 images.

This is the best example of a nearly circular delay-Doppler distribution
for the tear-shaped feature that was seen on August 1, 2, and 3.  That 
feature on August 8 has a visible range extent of about 0.9 km, which is
substantially less than suggested by the August 1 and 3 images but is
closer to the extent from the August 2 image. 

The large concavity seen previously seems to have more of its interior 
illuminated on August 8.  The concavity appears to be somewhat angular 
and it is about 1.5 km across and close to 1.4 Hz wide.  The distal 
arc of points at the negative limb is on the negative limb and is now 
seen to be the rotated "indentation" that was prominent on the approaching 
limb on August 5.  

AUGUST 9:
---------
This is the highest resolution view of 1999 JM8.  The delay-Doppler 
distribution is parabolic and indicates that the portion of the asteroid 
that was imaged is rounded.  Nevertheless, the image is asymmetric: there
are more distal points at negative frequencies than at positive frequencies.
One of the two prominent craters that is evident in the August 8 images is
located just negative of zero Hz on August 9.  The crater has dimensions of
1.1 km x 0.22 Hz.  The big concavity seen on August 8 is largely in 
radar shadow on August 9.  As was the case on August 2, the crater has
a distinct group of bright pixels inside it near the distal rim.  The pixels
look like a topographic high.  There is another large region just positive
of zero Hz that looks like another large concavity.  It has dimensions of
1.4 km x 0.21 Hz.   

Other thoughts:

No obvious ejecta in the images except for the radar-bright annulus surrounding what
appears to be a ~100-m crater in the July 28 image.  No obvious rays.

There are several linear features but their origins are not clear.  They might
be ridges.  More intriguing possibilities are that the prominent feature
on August 3-5 might be a fault or a groove, neither of which has been seen
before among radar images of NEAs.  The location of this feature on the shape
model should elucidate its origin.  

None of the craters is complex: there are no central peaks or peak rings, 
nor are such features expected for such a small object due to its weak gravity.
We do not see compelling evidence of terracing or slumping in any craters, 
but there are enigmatic groups of bright pixels that appear in two of the
largest craters that are of unknown origins.  

How many craters or other concavities larger than about 1 km are evident?
There are about 4.  

In retrospect, there is a hint of the large concavity in the images as soon as
July 23; the concavity is clearly present in the July 24 images. 

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

                        2000 January 27 & 28

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

Did the bandwidth change between days when the delay-Doppler images look similar?

Compare July 24 and August 1:

Jul 24   1.73 Hz
Aug  1   3.05 Hz
<Aug  8  3.38 Hz>

The bandwidth increased by a factor of about 1.8, so the subradar latitude was 
moving toward the apparent equator.  However, this ignores NPA rotation, which 
almost certainly plays some role, so we need the results from the modeling.

Comparison with the Aug 8 bandwidth isn't as meaningful because the orientation,
although similar, was distinctly rotated relative to that on the other two days.

The time base between Jul 24 and Aug 1 was slightly less than 8 days.  Using the
midpoints of the two images, the difference was .  Sky motion during that interval
was about 50 degrees.  Following a simplistic line of thought in which NPA rotation
and synodic rotation are ignored, this suggests that the subradar latitude moved
from relatively high values, say, more than 45 deg, to within a few tens of deg 
of the equator.  

- - - - - - - - - - 

I just discovered a useful trick for stopping the lexmark printer if it's spewing
large numbers of pages: pull out the paper tray to stop the printing, then use
the menu button to reset the printer.  That will flush the current buffer.  
It's often not possible to stop a job from the console because the print job moves
into the printer's memory very quickly and out of the queue, so lprm won't help.

- - - - - - - - - - 

Is the "twin peaks" region seen on July 28 the same as the "indentation" that is 
evident from August 5-7?  If the major component of rotation is close to 8 days,
then we would expect to see the twin peaks feature again on August 5.  The orientation,
resolution, and SNR are very different between the two days, perhaps masking the
similarity.  Perhaps the July 28 and August 6 images are a better match in terms
of orientation.  The shape model should answer this question.

- - - - - - - - - - 

One significant conclusion and distint difference relative to Toutatis: 1999 JM8
shows no obvious evidence for bifircation.  The elongation is more difficult to
estimate due to the NPA rotation and the significant sky motion, but thus far I
haven't seen evidence that JM8 is unusually elongated.  That is, my best estimate
of the elongation from the Doppler dispersions in images obtained between
July 31 and August 9 is about 1.2.  I chose thoses dates because we have an image
on each day and there appears to be slightly more than one rotation.  (Some of the 
rotation is due to the ~42 degrees of sky motion during that interval.)  If one 
naively uses the full variation in bandwidths over the whole experiment, then one
would conclude that the elongation is about 2.4 (Goldstone images).

- - - - - - - - - - 

How many craters or other concavities larger than about 1 km are evident?
There are at least two: The two that are so prominent on July 24, August 1, 
August 2, and August 8 (one is also visible on August 3 and 9).  The big 
concavity mentioned on several days is another candidate, as is a significant
concavity that is obvious only on August 9.   

        Dates crater    delay
Crater   is evident   extent (km)
------  ------------  -----------
1       Jul 24, 31      0.9
        Aug 1, 2, 8 

2       Jul 24, 31      1.2 (Aug 1, 3)
        Aug 1, 2, 3,    0.8-0.9 (Aug 2, 8)
        8, 9 

3       Jul 23, 24,     1.5 (Aug 8)
        Aug 1, 2, 3
        8, 9

4       Aug 2 ?, 9      1.4 (Aug 9)

Concavity #2 is puzzling: the "oblique" views on Aug 1 and 3 suggest it is close to 50%
larger than the views on August 2 and 8.  Why?

Interesting exercises
=====================

1. Use the bandwidths on July 24 and August 1 and sky motion to constrain diameter, 
then compare that estimate with visible delay extents.

Use the X-band data

Date    bandwidth
Jul 24   1.73 Hz
Aug  1   3.05 Hz

Difference: 3.05/1.73 = 1.76.  

Mid-epochs:
  date      duration        mid-epoch
Jul 24  18:01:51-19:59:54   19:00:53   
Aug  1  12:34:18-15:59:09   14:16:44
Elapsed time: 7 days, 19.264 h or 187.264 hours or 7.80 days

Use Horizons to get the RA and DEC at those epochs:

 1999-Jul-24 19:00 *   145.83595  65.53778
 1999-Aug-01 14:16 *m   78.24947  33.85424

reason:/data/ast5/1999JM8/analysis < 23 > angle
  
Enter RA1 (deg):
145.84
Enter DEC1 (deg):
65.54
  
Enter RA2 (deg):
78.25
Enter DEC2 (deg):
33.85
  
Angle =    50.3479

Steve discusses using two measurements of B at widely separated sky positions
in his paper "Physical properties of asteroids from radar observations" which
was published in "The Evolution of the Small Bodies of the Solar System" in
1987.  I had read that before but never fully understood some key concepts.
Now I do.  

Let's define alpha as the aspect angle, that is, the angle between the radar
line of sight and the object's spin vector.  Further, define alpha1 = alpha
for the first measurement and alpha2 = alpha for the 2nd measurement.  Then
the angular separation gamma = alpha1 + alpha 2.  

Further, recall that B = 4 pi D sin(alpha)/(lamda P)
Since we have two measurements of B, the bandwidth equation for one
measurement by the bandwidth equation for the other measurement, giving:

B1/B2 = sin(alpha1)/sin(alpha2)

Since gamma = alpha1 + alpha2, we can substitute for alpha1 giving:

B1/B2 = sin(gamma - alpha2)/sin(alpha2).

Now apply the trig rule: sin(a-b) = sin(a)cos(b) - cos(a)sin(b), 
then solve for alpha2 giving:

sin(alpha2)/cos(alpha2) = tan(alpha2) = sin(gamma)/(B1/B2 + cos(gamma))

From this we can compute both aspect angles (and thus subradar latitudes)
and place a strong constraint on the pole direction.  

Interesting points: this doesn't depend on the diameter or directly on 
the rotation period.  In the ideal case this applies to a spherical target
but even if the target isn't spherical, one can use this if delay-Doppler
images on different days look very similar (as is the case with JM8). So
applying this to JM8 *does* depend on the rotation period because that's how
we choose the epochs and thus bandwidths to compare.

For 1999 JM8 there appears to be rotation about more than one axis, but if
we ignore that and forge ahead, here's what we get:

Let 1 refer to the smaller bandwidth and 2 refer to the larger bandwidth.

Then tan(alpha2) = sin(50.3)/(1.73/3.05 + cos(50.3))
                 = 0.638
         alpha2  = 32.54 deg  => delta = 57.46 deg

Thus alpha1 = 50.3 - 32.5 = 17.8 deg => delta = 72.2 deg.

The implication is that the instantaneous subradar latitude was pretty
high on both days.  If JM8 were a PA rotator, then we could use Scott 
and Keith's polesearch software but since there are strong indications that
JM8 is an NPA rotator, that wouldn't accomplish much.  

If we accept a synodic period of 7.80 days from the radar images, 
then the bandwidth and subradar latitude on August 1 imply that JM8
has a large diameter:

D = (3.05 Hz)(187.3 h)/[(100)(cos(57.5))]
  = 10.6 km

We observe a maximum delay extent on Aug 1 at Arecibo of 4.50 km, so if
we assume that the true range extent is twice that, then that corresponds
to a diameter of about 9 km, which is almost certainly too large.  If we
adopt Pravec's period of 6.76 days, then we get D = 9.2 km which is 
more consistent but still probably too large.  

Scott's 2nd iteration shape model based on 6 days of Goldstone images
gives a maximum dimension of 5.2 km.  The Arecibo image on Aug 6 has a 
maximum range extent of 5.3 km, so we already know that Scott's preliminary
estimate is too small.  

So if JM8 is larger...then will that decrease the optical geometric albedo
into the range of C-type objects?  If so, then this is our first close
look at a C-type NEA and only our 2nd close look (excluding KY26) at a
C-type at all (the other was Mathilde by NEAR).

reason:/data/ast5/1999JM8/analysis < 27 > pvd
  
Enter the absolute magnitude:
15.2
Enter the diameter (km):
4.0
  
 H =     15.200
 d =      4.000
  
  pv           D (km)
 0.091         4.000

--> It looks increasingly likely that JM8 is an optically dark object.

As a simple exercise, compute the mean visible range extent from the 
Arecibo images: 4.2 km.  Note that these observations cover about
one rotation.  In the unlikely event that the visible range extent
equals the actual range extent, which it doesn't, then that still
implies that JM8 is big and optically dark.  The size that Scott 
obtained from the first 6 days is almost certainly too small and
by a substantial factor.  What does that say about the effective
diameters he has obtained for other, weaker targets?  

The effects of the greater S/N at Arecibo on the visible range extents 
are dramatic.  

- - - - - - - - - - 

2. Use sky motion and similarity of the images on July 24 and August 1 to get
the sense of rotation directly.  

This is complicated by the fact that we don't know the rotation period precisely:
Pravec's estimates have considerable variation and they don't seem to agree with
the radar images unless JM8 has only one minimum and one maximum.  

JM8's motion was toward decreasing right ascension; that is, toward the west.

Either retrograde or direct rotation satisfies the appearance in the images on
July 24 and August 1, but the two senses of rotation imply different rotation
periods: the period would be longer if the rotation is retrograde and
vice versa.   Let's accept that the images show the same side of the object.

The mid-epochs of the observations are:

  date      duration        mid-epoch
Jul 24  18:01:51-19:59:54   19:00:53   
Aug  1  12:34:18-15:59:09   14:16:44
Elapsed time: 7 days, 19.264 h or 187.264 hours or 7.80 days

Pravec's most recent reported period is 6.76 days, which is about 1 full day
less than suggested by the radar images.  

If the rotation is direct, then the apparent rotation period of 7.80 days is
shorter than the true period.

If the rotation is retrograde, then the apparent rotation period of 7.80 days
is longer than the true period.  To be consistent with Pravec's result, 
retrograde rotation is necessary.  

Forging ahead with a simplistic analysis, if Pravec's rotation period is
correct, then the difference in rotation should be about 46 degrees 
assuming very favorable geometry and assuming that we can ignore rotation
about the other principal axes.  Surprisingly, that's actually
consistent with the sky motion between July 24 and August 1: 49 deg.

Scott's 2nd iteration shape model had components of rotation of 
(3, 19, -29 deg/day) about the principal axes.  That's from a very
preliminary shape model (only 6 days of data, not much work to
really nail the spin vector) but it's consistent with retrograde rotation.

Thus, several lines of evidence combine to strongly suggest that the
dominant component of JM8's rotation is retrograde with a period of 
close to 6.8 days.  

We can test that conclusion by comparing the images from August 1 and 8,
which show similar views of JM8.  

Aug 1  12:33:37-15:59:25  14.2753 h
Aug 8  14:29:39-17:08:07  15.8146 h

Difference = 7 d 1.539 h or 169.54 h = 7.06 days. 

Granted, the similarity between the echoes isn't as close as it was on
Jul 24/Aug 1--there appears to be a few tens of deg of rotation, so 
the comparison doesn't work as well.  

The sky motion was: 35.5 deg. 

Simplistic synodic rotation: 6.76 d/7.06 d = 0.96 -> 0.04(360 deg) = 15 deg
of rotation.  It looks like there's more than 15 deg of rotation between
the two images.  At any rate, I think this simple analysis puts us in 
the ballpark for largest component and sense of rotation.  

Have I got this backwards?  As JM8 moves west, if it rotates directly,
and if the spin vector is oriented north-south, then it should take
less time to return to the same apparent rotation phase, and vice versa.
The key is having images that show nearly the same phase on three 
rotations, which we have: July 24, August 1, and August 8.  Actually,
the key is August 8.  The correspondence on that day isn't close enough
to the other two days to be sure--there's rotation about more than one
axis.  I think that retrograde rotation is still the better explanation.

Here are JM8's coordinates at 0 h UTC between July 24-August 10:
                        RA (deg)  DEC (deg)  delta (AU)   deltadot
 1999-Jul-24 00:00 *m  154.41437  65.48882  0.0729799787  -7.69056
 1999-Jul-25 00:00 *m  143.33838  65.45964  0.0687160350  -6.86743
 1999-Jul-26 00:00 *   131.32287  64.45690  0.0649578359  -5.88191
 1999-Jul-27 00:00 *   119.38845  62.27087  0.0618018613  -4.72382
 1999-Jul-28 00:00 *   108.51756  58.86111  0.0593470104  -3.39796
 1999-Jul-29 00:00 *    99.25159  54.36930  0.0576840650  -1.93111
 1999-Jul-30 00:00 *    91.66133  49.06507  0.0568821013  -0.37460
 1999-Jul-31 00:00 *    85.55073  43.27591  0.0569754679   1.20127
 1999-Aug-01 00:00 *    80.64465  37.32662  0.0579563377   2.72116
 1999-Aug-02 00:00 *    76.68425  31.49334  0.0597762537   4.12115
 1999-Aug-03 00:00 *    73.45725  25.97670  0.0623559724   5.36002
 1999-Aug-04 00:00 *    70.79900  20.89670  0.0655993159   6.42138
 1999-Aug-05 00:00 *    68.58456  16.30462  0.0694061839   7.30876
 1999-Aug-06 00:00 *    66.71945  12.20255  0.0736818483   8.03791
 1999-Aug-07 00:00 *    65.13196   8.56266  0.0783420422   8.63002
 1999-Aug-08 00:00 *    63.76725   5.34219  0.0833147553   9.10712
 1999-Aug-09 00:00 *m   62.58290   2.49335  0.0885399893   9.48950
 1999-Aug-10 00:00 *m   61.54582  -0.03091  0.0939684988   9.79470

Skymotion per day (0 h->0 h UTC)
--------------------------------
Jul 24-25    4.6 deg

Jul 30-31    7.2 deg
Jul 31-Aug 1 7.0 deg
Aug  1-2     6.7 deg

Aug  5-6     4.5 deg

- - - - - - - - - - 

USE DELAY EXTENTS TO PLACE LOWER BOUNDS ON DIMENSIONS OF FEATURES
=================================================================
Can we use the delay extents and bandwidths of features in images
obtained on consecutive days (when there was little sky motion) to
constrain the km/Hz conversion?  

1. As an example, consider the big "flat" side that is so prominent
on August 4, 5, and 6.  It's oriented nearly broadside on Aug 5 but it's
tilted at a substantial angle on Aug 4 and especially Aug 6 (better S/N
than on Aug 4: more looks).  The bandwidth on Aug 5 is 1.01 Hz.  The delay
extent of the same feature on Aug 6 is at least 4.8 km.  The Aug 6 image
has lower S/N and not all of the flat side is illuminated, but clearly 
more than 90% of it is.  The side isn't oriented along the LOS either
but it appears to be within a few tens of deg of "vertical."  

So we get 4.8 km/1.01 Hz.  That side is AT LEAST 4.8 km long.  It's huge!

So we could apply the same reasoning to the craters and other features
seen on those two days.  

2. "Indentation" on Aug 5 and 6

It has a delay depth of approximately 1.9 km.  

3. ~linear ridge that is most prominent on Aug 4.

It has a bandwidth of about 0.50 Hz.  It's not oriented along the LOS in
any of the images but it seems to be at it's steepest angle on Aug 3:

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

                        2000 January 31 & Feb 1

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

I wrote a short FORTRAN program to estimate NPA damping timescales using the
expression in Harris (1994).

Here are examples for JM8:

Deff = 8.4 km
=============

reason:/home/lance < 1 > damping
  
Enter the rotation period in hours:
162.24
Enter the effective diameter in km:
8.4
  
period (h)  =    162.2400
  deff (km) =      8.4000
  
tau (10^9 y)    +        - 
---------------------------
 12.319     164.131  11.502

Deff = 4.2 km
=============

reason:/home/lance < 1 > damping
  
Enter the rotation period in hours:
162.24
Enter the effective diameter in km:
4.2
  
period (h)  =    162.2400
  deff (km) =      4.2000
  
tau (10^9 y)    +        - 
---------------------------
 49.275     656.524  46.008

If 6.76 days is a good approximation for the rotation
period of JM8, then given the visible range extents and the lower 
bound (4.2 km) on the effective diameter that is implied, it's clear
that we would expect JM8 to be a non-principal axis rotator.  

If Scott's estimate of Deff = 3.5 km is correct, then the nominal damping
time increases to 71 E 9 y.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Surface bulk density
====================
The X-band circular polarization ratio of JM8 indicates that most of the
echo power comes from single back reflections.  Consequently, we can relate
the OC radar albedo to the normalized reflection coefficient and thus
back out constraints on the surface bulk density (refs).  In the absence of 
a 3-D shape model we do not know the gain g, but from previous shape 
reconstructions we have found that g does not usually differ from unity by
more than several tens of percent, which is less than the adopted systematic
uncertainty in the radar cross section, so, to first order, we can assume
that g = 1.  Then R = the radar albedo +/- 100% and the bulk density 

d (R) = 3.2 ln[(1 + sqrt(R))/(1 - sqrt(R))].

d (R = 0.034) = 1.2 g/cm^3
d (R = 0.14)  = 2.5 g/cm^3

We really can't do much until we have a better estimate for Deff.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

It's obvious that we'll need to write an Icarus paper to do this object 
justice.  The question becomes whether or not we can also make the case
for a Science paper.  That depends on the shape model and what we extract
from it.  Regardless, I'm going to draft an Icarus paper first and then
assess whether or not to approach Science and Nature with a shorter 
manuscript.

Possible collaborations
=======================

Clark Chapman?
--------------
We have also addressed whether or not to invite Clark Chapman to join
us as a collaborator to work on the distribution of impact craters and
their significance.  Steve seems eager to do this.  I gather that he 
and Clark have a good relationship, but I think Steve is also looking 
to bolster political support for what we do by bringing Clark on board.
On the other hand, R-plots and d/D plots aren't all that difficult to 
do or understand, so I'd prefer to do that myself.  Once Scott and I 
establish criteria for what constitutes a crater (or, at the least,
a concavity) then we can forge ahead.  I'm not averse to working 
with Clark (I have great respect for his work and I'm rather fond of
him personally) but I don't see that we really need him.

It's also not yet clear how far we can go with crater analyses.

Although there are many craters, a quick visual inspection suggests 
that the surface isn't even close to saturated.  That is something that
we'll be able to test using the larger craters. 

The abundance of large craters raise the obvious question of the
effects that they've had on the spin vector of JM8.  If the features
about 1.4 - 1.5 km in diameter are craters, could they deliver enough
momentum to produce the spin state?  Or *remove* enough?  There are
enough large craters that it seems unlikely that JM8's spin state 
is primordial.  

Erik Asphaug & Dan Scheeres?
----------------------------
Erik Asphaug's impact modeling could prove quite useful and perhaps 
we could make some sense of the bizarre shape, large craters, and spin
state by doing impact simulations (in collaboration with Scheeres?).
It would make sense for Erik or Dan to be lead author.  Another important
question to address: is JM8 a rubble pile?  How much of JM8's interior
could the impactors that produced the craters plausibly fracture?  
Enough to rubblize JM8?

Petr Pravec?
------------
Steve thinks we should invite Pravec to join us on an Icarus paper and I'm 
inclined to agree.  I had rejected this idea earlier but I'm coming around
to believe that it would be worthwhile to back out Hapke parameters and
show the orientation of JM8 on the sky during lightcurve observations as
Scott has done with other objects.  Ideally it would be good if Petr publishes
the photometry separately, as he did with Bacchus. 

Ellen Howell and Michael Hicks?
-------------------------------
They both got vis-IR spectroscopy and Hicks got thermal IR radiometry.
I'd be glad to go in with Ellen as lead author--we could show the orientation
of the shape model when they were observing so we could potentially 
identify where optical spectral features are located on the surface.

The collaboration with Hicks could prove to be a useful calibration of 
the thermal models and a natural follow-up to Golevka.  

David Rubincam/Bill Bottke?
---------------------------
Do Yarkovsky forces affect the orbital and spin evolution of JM8?  
We could numerically integrate the orbit using the SWIFT code by 
Levison and Duncan and tap into David and Bill's expertise.  This
might work better with just David, but Bill could be a good liason
since I don't know Rubincam personally.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

COMPARE JM8 WITH OTHER RADAR-DETECTED DARK OBJECTS PLUS MATHILDE
================================================================

It's clear now that JM8 is an optically and radar dark object.  It's the best
look with radar that we've ever had at such an object, but there are still
others with which we can compare it: Mathilde, Phobos, Deimos, and possibly
Ra-Shalom, 1986 JK, Betulia, and 1998 KY26.  

KY26 is so drastically different
due to its small size, rapid rotation, and weak gravity that a comparison
may not be very meaningful.  For KY26 SC/OC ~ 0.5 and the radar albedo is
between 0.012 and 0.11.  The radar albedo estimates overlap very preliminary
estimates for JM8.  

We don't know the radar albedo, effective diameter, or rotation period of 
1986 JK.  SC/OC = 0.26+/-0.02.  That's close to estimates for JM8, but it's
also close to the mean for ALL radar-detected NEAs, so it doesn't say much
(yet).  Correction: Steve estimated the radar albedo by adopting the best
available estimates of the effective diameter from optical observations of
H and the taxonomy, suggesting that the radar albedo is between 0.0053 and
0.067.  The upper limit is consistent with that of JM8.

1580 Betulia was observed at both 3.5 cm and 13 cm in 1989.  SC/OC is 0.18+/-0.03
at 3.5 cm and 0.16+/-0.01 at 13 cm.  In the 1986 DA paper Steve reported that
the radar albedo of Betulia is about 0.09, which is also consistent with
the preliminary estimates.

How well does the radar albedo of JM8 compare with the mean and rms 
dispersion observed among radar-detected main-belt targets?  Chris Magri found
that the main-belt C- and S-class radar albedos are indistinguishable.  The
lowest is 0.11 (Daphne) and a few others are about 0.13.  Some, however,
are as large as 0.23.  Perhaps it would be more appropriate to compare 
the radar albedo of JM8 with the BFGP objects.   Most of their radar albedos
cluster at less than 0.1, although one (554 Peraga, type FC) is about 0.2.

Conclusion: radar albedo of JM8 is consistent with other radar-dark C- and 
BFGP-type objects.  SC/OC is less diagnostic due to the substantial observed
range of values.  

What about Phobos?  
Steve mentioned that he's almost sure that the radar cross section and radar
albedos that he published for Phobos are too small: he didn't trust the Goldstone
calibration, which he later discovered were reliable.  Steve's nominal estimated
albedo is 0.093+/-0.035, which is consistent with results for JM8, although the
consistency isn't as good if Steve's estimate is too small by ~20%.  
SC/OC = 0.09+/-0.10, so the decimeter-scale surface is smooth.  This is all based
on a ~9 sigma detection.  SC/OC is about a factor of two smaller for Phobos 
than it is for JM8.  Again, I don't think that SC/OC has reliable correlations
with composition.

Mathilde
Mathilde is about an order of magnitude larger, but like JM8, is is optically
dark (a C-type) and it has several very large craters relative to its diameter.
Mathilde actually has *more* craters large compared with its diameter than
JM8 does.  Perhaps a better analogy with large craters would be Ida... 

Ida
Ida is an S-type.  Its effective diameter is 15.7 km.  The largest craters are
about 14 km in diameter; according to Chapman et al. (1996), there are 12 craters
with diameters exceeding about 5 km, that is, with crater diameter/asteroid 
effective diameter ratios > 0.2.  We don't know Deff of JM8 yet, but it already
seems unlikely that there are this many relatively large craters on JM8 (only 4
obvious in the images have D >~ 0.9 km).  

Tisserand Parameter for JM8:
============================
reason:/data/ast5/1999JM8/analysis < 7 > tisserand
  
Enter the semimajor axis (AU):
2.72
Enter the eccentricity:
0.644
Enter the inclination:
13.69
  
  2.720    0.644   13.690
  
q =    0.968
Q =    4.472
  
TISSERAND PARAMETERS
Neptune: T =   11.499
Uranus: T =    7.615
Saturn: T =    4.301
Jupiter: T =    2.988
Mars:    T =    2.546
Earth:   T =    2.819
Venus:   T =    3.149
Mercury: T =    4.083

T = 2.988 is suggestive of a comet, but it's not compelling evidence: Valsecchi
et al. (1995) found dynamical pathways between NEAs and JFCs so the distinction
based on T is not robust.  Encke is a good example of an object with an NEA
orbit that is obviously cometary.  However, an inactive comet nucleu is an 
intriguing possibility for JM8...we know that JM8 is dark, in agreement with the 
best-known comet nucleus albedo, Halley.  There is strong evidence that Halley
is a NPA rotator too.  Need to get the refs... Belton et al.?  

The orbit of JM8 is almost surely chaotic, given that it crosses the orbits of 
Earth and Mars and approaches that of Jupiter.  Just for fun I could fire up my
old code and numerically integrate it for +/- a few thousand years, or I could
do a more robust but shorter integration using Horizons.  Track the evolution
of the elements, close approach distances, and the evolution of T...estimate
Lyapunov times.  It's obvious that it's chaotic.  Whether or not JM8 is a 
comet is a much more important question because we've never (to our knowledge)
seen a comet as well as we've seen JM8.

The semimajor axis of JM8 is comparable to but somewhat less than that of 243 Ida.

I should write a short Perl code to parse the MPC NEA list files, compute 
Tisserand parameters, and then sort them.  It might also be interesting to 
compute their mean, standard deviation, and plot a histogram.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Is JM8's orbit close to a strong mean-motion resonance with Jupiter?

reason:/home/lance < 1 > resonance 
  
Mean-motion resonance maximum order = 25
Only matches within 0.01 of a resonance will be output
  
Enter the period of the minor body (yr):
4.495  <== THAT'S WRONG!
  
Planet convention: Mercury = 1, ..., Pluto = 9
Enter number of innermost planet to consider:
3
Enter number of outermost planet to consider:
6
  
Earth  
Period/period of Earth   =  4.4948
      Expected  Difference
        ratio
 2: 9 =  4.5000    0.0052
  
Mars   
Period/period of Mars    =  2.3898
      Expected  Difference
        ratio
  
Jupiter
Period/period of Jupiter =  0.3789
      Expected  Difference
        ratio
 8: 3 =  0.3750    0.0039
13: 5 =  0.3846    0.0057
18: 7 =  0.3889    0.0100
21: 8 =  0.3810    0.0020
  
Saturn 
Period/period of Saturn  =  0.1526
      Expected  Difference
        ratio
 7: 1 =  0.1429    0.0097
13: 2 =  0.1538    0.0013
19: 3 =  0.1579    0.0053
20: 3 =  0.1500    0.0026
25: 4 =  0.1600    0.0074
  
Closest mean-motion resonance detected:
Saturn 
Ratio of periods =  0.1526
13: 2 =  0.1538    0.0013

This isn't as useful as it could be: I should modify resonance.f to
compute the heliocentric semimajor axes of each resonance for 
comparison.  Could even estimate the change in orbital energy
necessary to get there from the present orbit.

I modified my software "resonance.f" to output the semimajor axis corresponding
to the close resonances and the difference in AU between the sma of the resonance
and the asteroid.  Here's the result for JM8 relative to Earth and Jupiter:

Earth  
Period/period of Earth   =  4.4858
      Expected  Difference
        ratio
 2: 9 =  4.5000    0.0142      2.7258    0.0058
  
Mars   
Period/period of Mars    =  2.3850
      Expected  Difference
        ratio
 5:12 =  2.4000    0.0150
 8:19 =  2.3750    0.0100
  
Jupiter
Period/period of Jupiter =  0.3782
      Expected  Difference
        ratio
 8: 3 =  0.3750    0.0032      2.7048    0.0152
11: 4 =  0.3636    0.0145      2.6499    0.0701
13: 5 =  0.3846    0.0064      2.7508    0.0308
18: 7 =  0.3889    0.0107      2.7712    0.0512
19: 7 =  0.3684    0.0097      2.6731    0.0469
21: 8 =  0.3810    0.0028      2.7333    0.0133
23: 9 =  0.3913    0.0131      2.7826    0.0626
25: 9 =  0.3600    0.0182      2.6322    0.0878

Threshold to display: difference of <= 0.02 in the period ratio.

The difference between the orbit of JM8 and the 21:8 resonance is only
0.013 AU or about 5.1 lunar distances.  That's pretty close.  

The 2:9 resonance with Earth is only about 2.2 lunar distances from
JM8's semimajor axis.  JM8 is closer 
to the 2:9 resonance with Earth in terms of semimajor axis than it is
with any Jovian resonance by at least a factor of 2.3.

How do you gauge the "strength" of a mean-motion resonance?  We need to know
that to assess which resonance is more important.  This is a minor issue
that we don't need to answer immediately--there are other more important
issues to deal with, so return to this later.  Perhaps the answer is 
related to the change in orbital energy that's necessary to drive an object
into a resonance coupled with the magnitude of perturbations that a given
planet can generate, which, in turn, are likely proportional to Mplanet/r^2.  

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

                        2000 February 2 & 3

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

Tisserand parameter revisited
=============================
I was curious about how unusual the Tisserand parameter for JM8 really is, so 
I modified my Perl script for computing and ranking delta_v for flybys to 
compute and rank NEA Tisserand parameters.  Of 888 objects in the 2000 Jan
27 lists from the MPC, JM8 ranks 50th, that is, it's less than about 94%
of all NEA Tisserand parameters.  This doesn't include Jupiter-
family comets.  I posted the results on the web at:

echo.jpl.nasa.gov/~lance/tisserand/tisserand.html

Thus, although T for JM8 is similar to that of JFCs, it's also consistent
with those of a subset of NEAs, 49 of which have smaller values.  Those
other NEAs generally have semimajor axes > 2.6 AU and many occupy orbits
with eccentricitis > 0.5.  Thus, the Tisserand parameter by itself is not 
compelling evidence that JM8 is an inactive comet nucleus.

This would seem to confirm the results of Valsecchi et al. (1995), although
it's also conceivable that some of these objects are inactive comets.

It would be interesting to prepare a histogram of the Tisserand parameters.
Save that for some other time.  

There's only one other NEA with T < T for JM8 that has been detected by radar:
1986 JK   T = 2.9337

Here are the next five radar-detected NEAs in order of ascending T:

Rank  Object               Provis. desig.      T
----  ------               --------------    ------
63   (8201)                    1994 AH2      3.0242 
68   (1036) Ganymed            1924 TD       3.0349
71   (6178)                    1986 DA       3.0387
81   (1580) Betulia            1950 KA       3.0659
93   (4197)                    1982 TA       3.0890

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I'm still pounding away on the draft Icarus manuscript.  There's a lot to cover...
it's almost overwhelming.  Steve wants a draft of the whole thing (including the
shape model) by the end of the month.  It's my hope to have a first draft of
everything except the shape model by the end of next week.  The most challenging
section to write (w/o the shape model) is the description of the images.  That's
next...  then go back to fill in more of the intro, the CW results, the astrometry
(to the extent that we can complete it), and the discussion.  

I haven't done much yet with the figures: the imaging figures will be a good
reason to plunge into IDL.  We'll need logarithmic stretches for most.
The SC/OC figure is doable using screen-grabbed gifs 
from Transform imported into Tkpl, but it might be easier using IDL.  

Another project for IDL: skymotion plotted on a sphere.  There really aren't that 
many figures that I can create without the shape model.

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

                        2000 February 4

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

Continuing to work on the draft.  I'm reading some of the Mathilde papers
to check that I've covered the important issues that we can address.

One thing we haven't mentioned in any of our papers is a satellite search.
I've done some simple calculations for 1998 ML14 and for JM8 to see whether
or not the Goldstone and Arecibo images covered enough range and Doppler
frequency to include likely asteroid orbits, using the Hill sphere as a 
guide.  We could refine that by referring to the results from Hamilton
and Burns (1991) but it won't make much of a difference except for 
pathological retrograde orbits.  I mentioned to Mike Nolan and Jean-Luc
Margot that we should consider satellite searches when I was at Arecibo
in August.  We did a couple of runs with a 4-usec baud on August 1 with
a 65535 code that more than encompasses the Hill sphere, and I checked
that image when I was at AO for possible secondary echoes.  I found none.
The Gaspra, Ida, Mathilde, and Eros papers have all discussed satellite
searches and with Ida they found one.  Since the caliber of our observations
is better than that of the 1998 Eros flyby, should we discuss satellite 
searches too?  I'm inclined not to since there's already so much to 
cover, but it might be good to put something in print to let the community
know that we're looking and what our techniques are.  Satellite searches are
another good argument for using really long codes at Arecibo in order to 
cover lots of range.  On the flip side, though, long codes limit our
ability to sample widely in Doppler frequency, so it's conceivable that
in so doing we could miss a satellite outside the passband.  For example,
using a 65535-code with a 0.1 usec baud gives a bandwidth of only 152 Hz.
We don't use such long codes at Goldstone so it's less of a problem there,
although, of course, the drawback is that the system isn't as sensitive.  
We didn't exhaustively search the Arecibo 0.1 usec images: there were so
many pixels that Mike Nolan (correctly) vignetted the echo and ignored
the rest.  

Perhaps insert a concise paragraph summarizing what I wrote above...?

Issues: Diameter from Hamilton & Burns & comparison with Hill sphere.
          -Depends on asteroid's effective diameter and density.  Assume
           plausible upper and lower bounds on the density and compute.
        Doppler frequencies covered and expected shifts from plausible
           orbits
        Bauds and frequency resolutions vs. size and rotation period of 
           satellite
        Registration of the images vs. time: satellite motion will smear
           the echo in delay and Doppler.

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

                        2000 February 8

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

I backed up the JM8 reduction log and draft manuscript onto
think:/public/protected/lance/1999JM8/

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Radar bright annulus on July 28
-------------------------------
Near the center of the July 28 image is a radar-bright annulus encompassing
a group of pixels that are about 100 m in diameter, suggesting a small impact crater 
with a radar-bright feature surrounding it.  Radar-bright features surrounding 
impact craters have not been seen previously in radar images of asteroids, but
they have been found surrounding impact craters in Haystack (Thompson et al. 1981)
and Arecibo (Stacy et al. 1997) radar images of the Moon and in Arecibo 
(Burns and Campbell 1985, Campbell et al. 1990), Goldstone (Jurgens et al. 1988),
Venera (Basilevsky et al. 1987), and Magellan (Phillips et al. 1991) images of Venus.
The feature on 1999 JM8 may be the signature of an impact crater with a rough 
surrounding near-surface at decimeter spatial scales.  If the annulus formed as a result of 
an impact, then it may be geologically young because impact gardening 
should remove such features over short geologic timescales.  Significant regolith 
retention is not expected on JM8 due to its weak gravity, so if the annulus
does surround an impact crater, then it may be the result of proximal 
surface shaking, as Asphaug et al. (1996) proposed to explaing optical annuli 
surrounding craters on 243 Ida.    

The literature on radar observations of Venus and the Moon is vast, so there
may well be earlier papers that report bright annuli surrounding craters than
the ones I cited.  From my brief perusal of several papers, it appears that 
Don Campbell et al. weren't sure in early Arecibo images whether or not they 
were seeing impact craters or volcanic craters (as it turns out, the answer is
probably both), so they didn't make definitive claims.  

 
Use the shape model to locate this feature on the asteroid and determine whether
or not we imaged it on other days.  ==> USE TRACE 

See bright rims in SC images of the Moon from Haystack data (Thompson et al. 1981)
and from Arecibo SC and OC images of Venus (Campbell et al. 1990, GRL 17, 1389).
Stacy et al. (1997) reported bright SC rims on the moon and bright SC/OC features
associated with some craters.  The potential youthfulness of this feature is 
important.  We haven't seen radar-bright crater rims on asteroids before.

To assess the number of craters on August 4-6, print out SC and OC images, then
circle and number the features.  For now I'm using visual inspection.  I compare
images on different days to verify that features repeat.  Some of the features
that I'm circling are on the edge--my best estimate is that they're craters but
the evidence isn't overwhelming.

Estimate the crater dimensions using the range extents (using my best esimates
for the crater rims):

Date   Possible craters
----   ----------------
Aug 4    4   All are evident on August 5
Aug 5   25   
Aug 6   15   Most are evident on Aug 5, but 3 on the approaching limb aren't.
             Crater identifications on Aug 6 are difficult due to SNR

          Units: meters
            Aug 4         Aug 5         Aug 6 
feature  range extent  range extent  range extent
-------  ------------  ------------  ------------
 1           675          405
 2           285          270
 3           435          435          360
 4           570          480          375
 5                        315          330
 6                        195
 7                        225
 8                        150
 9                        270
10                        195
11                        405
12                        600          495
13                        270          270
14                        195          225
15                        435          525
16                        450          405
17                        195
18                        180
19                        135
20                        135
21                        135
22                        270
23                        210
24                        360          270
25                        465          465
26                        225          
27                        165          315
28                                     360
29                                     Too vague: can't see rims.  May be 2+ craters.
30                                     Too vague: can't see rims
31                                     225

Some of the day-to-day estimates match well; others differ by up to a factor
of two.  The factor of two differences suggest I should discard one or both
estimates--perhaps I'm not seeing a crater.  Crater 27 is a good example: it's
very hard to locate in the August 5 image, but it's easier on August 6.  With
other examples, such as crater 12, it seems clear there's something there, but
the low S/N makes discerning the crater dimensions accurately difficult.

One way to improve the accuracy of these estimates is to measure them multiple
times: say, three times.  Ugh.  Hold off for now until we see what we've got.

I just noticed from careful inspection of craters on Aug 4 and 5 that the rotation
about more than one axis is evident in the images.  Specifically, craters 2-4
appear to be deeper into the echo from the LE on Aug 5 than on Aug 4.  This could
distort some of the images enough to make the visible range extents different.

What we can say with confidence is that we can see craters on these three days
(and on others) rotating in delay-Doppler from day-to-day.  That is, some craters
are clearly present in images on two or more days in succession.  Their range extents
place lower bounds on their dimensions, subject to projection effects.  Although
I'm not confident that all the proposed features are actually impact craters, the
August 4-6 images strongly suggest that there are many craters on the surface that
are between about 100-600 meters in diameter (perhaps even larger).  We tentatively
identify about 30 such craters from the images on these three days.  These craters
appear to be on the opposite hemisphere from craters seen on July 24, 31, August 1-3
and August 8-9 so I suspect that they aren't the same.  The craters on the other 
days were less numerous and much larger.  Seems to indicate a significant difference
between hemispheres, which would be interesting.  Why would one side have more
much larger craters than the other?  The side with large craters might not have
as many small ones because the big craters could have "erased" the smaller ones.

For the draft, don't put too much emphasis on the dimensions of the craters: base
that on the shape model.  

Crater 3 appears to have a radar bright annulus around it, although it doesn't
stand out as well as the one on July 28.  Using Transform, it is necessary to 
boost the saturation to about 200 sigma before this becomes evident.  This crater
is near the LE so perhaps that is facilitating seeing the rim.  From inspection,
this is the only other crater noted to date in which one can trace radar bright
pixels all the way around it.  One of the questions this raises is: how are we
defining a radar-bright rim?  There appears to be a continuum of rims--for example,
the tear-shaped features have radar bright perimeters that one can trace most
of the way around the dark pixels.  Clearly in many instances the near rim and distal
rims face the line of sight and thus are bright.  It's the orthogonal rims that
are intriguing.  The proximal radar bright rims are also interesting because
they probably indicate that the rims are topographically raised.  There's a general
tendency of nearly complete radar bright rims for craters that are closest to
the leading edge (Aug 5).  

Are stratigraphic relationships evident from any of the craters or other features?
I haven't seen any obvious evidence yet...but also need to be aware of the 
north-south ambiguity, which could make features appear to overlap.  There appear
to be a few clusters of adjacent craters such as 25, 24, 31; 3, 4; 6-10; and
perhaps 16-21.  

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

                        2000 February 9 & 10

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

I'm outlining more craters on the other days when we have enough detail and 
S/N to identify them.  Several of the craters visible on Aug 4 and 5 are also
visible on August 3.  Comparing those craters makes it obvious that the 
asteroid's apparent rotation is about more than one axis.  

I've tallied 14 likely craters in the August 3 image.  I'm pretty sure that
four on the approaching limb are visible on Aug 4 and 5.  There is a cluster
near the center of the Aug 3 image that may or may not be visible on Aug 5;
it's hard to tell because the rotation between the two days appears to be
about more than one axis, and because the craters are not evident in the Aug
4 image (the one where we got only 5 runs).  What I don't see is an obvious
correspondence between small craters on August 3 and small craters on Aug 2:
the region in the Aug 2 image where there should be craters doesn't show
any.  If we ignore the Aug 3 mystery craters that I can't confidently link
with those seen on other days, there are still about 40 craters that I have
identified elsewhere and I've made a point of being careful not to count the
same features more than once (I've numbered each feature on a hardcopy).
Obviously the shape model will help determine which features are actually 
concavities and their locations.

I labelled the ~40 craters on hardcopies of the images.  Perhaps IDL will
allow us to label the images directly?  Another cumbersome option would
be to use tkgraph: do screen grabs on the images, import into tkpl, then
use text, arrows, circles, and ovals to label possible concavities.  What
a tedious task!

I've been pushing the radar bright annulus surrounding a small concavity 
about 100 m in diameter in the July 28 image, but after looking at all the 
concavities, it's not clear to me that the one on July 28 is special.  I had
thought that it was reminiscent of radar bright rings seen around craters
on the Moon and Venus, but this begs the obvious question: how do you define
a radar bright ring?  With numerous concavities we see a narrow bright ring
that appears to coincide with the rim, but that's not unusual.  What _would_
be interesting would be if the annulus clearly extended beyond the 
concavity.  I don't think we have enough resolution with the July 28 feature
to claim that it does.  Let's just point it out as a possibility but not 
dwell on it.  It's always safer to underinterpret. Some comparison with 
bright rim craters on other objects is useful though.

I may have missed something important about the bright rims: the rim
of crater 36 is obvious when it's tear-shaped or elliptical (Aug 1-3, 8;
this is most obvious when it's near the approaching or receding
limbs). The rims don't appear prominent when the craters are near the "middle"
of the echo and appear "circular."  Crater 32 isn't as good an example, even
though it looks somewhat elliptical in some images.  Crater 36 appears
circular only on July 31 when it's a weak feature near the approaching TE.

Careful inspection of the July 31 and August 1 images reveals that I mislabelled
some features on the hardcopies.  The July 31 image clearly shows one big
concavity (#32) and suggests the other big one (#36) near the TE on the
approaching limb.  There are two other craters adjacent to #32: #37, which
is ~xx  in range extent, and #35, which is ~yy m in range extent.  35 and
37 aren't so obvious in the August 1 Goldstone or Arecibo images, but I've
finally found them in both.  What's intriguing is that #37 appears almost
inside #32 on August 1 and it clearly has a collection of bright "rim"
pixels on Jul 31 and Aug 1.  The bright rim is much more prominent in the
Arecibo image (but it's visible in the Goldstone image too), to the point 
that I did not recognize it as a concavity.  It appears that the proximity
of the two concavities lead me to think that #32 has a larger range extent
on Aug 1 than I previously thought.

Date   No. of concavities
----   ------------------
Jul 31   5 LOW RES GOLDSTONE
Aug 1    8 (Arecibo)
    2    9
    3   14
    4    5
    5   26
    6   15
    7    1 LOW RES GOLDSTONE
    8    3 LOW RES GOLDSTONE
    9    3

Ignoring the low-resolution Goldstone results, the fewest are visible
on August 9 and the most are visible on August 5.  There could well be
many other small craters close to the limit of the resolution that I'm
excluding (all the ones I've tabulated have range extents > 100 m).
There may be other concavities that are visible but that I haven't
recognized: this is reasonable because some are quite subtle.  

I went through the tedious task of estimating range extents for all the 
other craters, which I tabulated in file "concavity.dimensions"  There
are 43 features in the list.  There are six features visible on Aug 3
that I was unable to link with features on other days (especially Aug 5), 
but to avoid counting them twice, I ignored them on Aug 3.

It turns out that there are 3 features larger than about 1 km and 5 or 6
larger than about 500 meters.  About 1/2 are between 200-400 m in range
extent.  This isn't as robust as I would like, so I'm trying to be careful
and not draw sweeping conclusions.  I don't know if we'll be able to do
meaningful R-plots or d/D estimates for JM8, but we should be able to 
get meaningful information on the geographic distribution of features as
a function of size.

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

                        2000 February 16

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

Steve gave a talk on Feb 11 in which he showed gravitational slopes on the 
Golevka shape model.  Slopes exceed the angle of repose near particularly 
sharp topography that are mostly near the edges of the shape.  That means
that those regions are nearly devoid of regolith.  That offers some 
interesting opportunities: we could compare SC/OC maps with the surface
slopes to indentify whether roughness or lack thereof is related to 
regolith.  In principle, we could also estimate the % of the surface 
illuminated by the Sun (and even identify where, once we know the spin 
vector and shape model), and compare it with vis-IR spectroscopy.  We could
also compare with photometry to test theories about optical scattering by
regoliths and Shepard's lab measurements of the opposition effect on bare
rocks.  Ideally we'd like to make radar albedo maps to back out the surface
bulk density.  

At present we don't have calibrated delay-Doppler images but the other ideas
are tractable.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Greg Black has installed and tested tkrdfreduc and tkpl on his computers at
NRAO in Green Bank.  He also wrote and tested CW reduction software in IDL
and compared the results with those he got from tkrdfreduc using Arecibo 
Callisto data.  He found a bug in our software rnb.cc, which removes the 
noise background.  Evidently sdev is being computed correctly but the 
normalization of the spectra is not, so the net result is that the 
radar cross sections are about a factor of sqrt(3) too high.  Greg identified
the lines of code where the error exists and Mike Thomas is going to 
fix it.  

I noticed problems with the JM8 noise statistics last fall but
thought it was a problem with the tkpl filter, not the statistics themselves.
Yesterday I plotted noise statistics for a JM8 spectrum obtained on the
first day (199) with low freq. resn and about 480 looks: the noise wasn't
well fit by a Gaussian--there is an excess of ~1 sigma points.  I checked 
1991 CS spectra from DOY 240 and 241: the noise statistics look OK.  As 
a double check, I converted the CS files into the old PLAY format and 
checked the noise with that software too.  The results aren't identical to
those obtained with TKpl (because we don't know the number of bins that
PLAY uses in its histograms), but they're a close match.  

This raises obvious questions:

1. Is Greg right?  Why didn't we notice this before?

2. If Greg is correct, then some of our published radar cross sections, radar
albedos, and surface bulk densities are incorrect: they're a factor of 1.7
too small.  

3. Is this a problem only with the VME format CW data or with _all_ the
CW data, including old cw data obtained with Goldstein's IBM?  

4. Why do we get an excess of 1-sigma points with the JM8 spectrum?  Is it
an artifact of not having enough Doppler bins (only 128)?  --> Could test
with 4 kHz sampling data. 

5. Recent published objects that could be affected: 1998 KY26, Toutatis (1996),
Bacchus, 1991 CS, 1992 QN, 3103 Eger, 2062 Aten.  Current papers in progress:
1999 JM8, Golevka, 1999 GU3, and maybe 2100 Ra-Shalom.  

Other implications: the radar cross section of Mercury.  That's been down 
by several dB for at least several months.  Is part (or most) of the problem 
with our software?  I suspect not because Ray Jurgens got results nearly the
same as mine using independent software.  Does Ray's software make the same
mistake as ours?  That doesn't seem likely.

I have a hard time believing that the radar cross section of Bacchus is 
larger by a factor of 1.73 becauase that would increase our nominal radar albedo
to 0.56, which is VERY high.  That's comparable to the radar albedo of 1986 DA,
which is a metallic object.  Bacchus isn't metallic (optical spectroscopy places
it among the Q-S continuum), but this would bolster the case that it may be 
bare rock or stony/iron.  The factor of 1.7 would increase the normal reflectivity
coefficient R to 0.40 and the bulk surface density to 4.8 g/cm^3 (from 3.3 g/cm^3).  
That increase in R would effectively rule out an ordinary chondrite composition
for Bacchus in favor of a stony-iron or iron composition, neither of which is
favored by the optical spectroscopy.  That is hard to believe...  

The issue may be Goldstone's tendency to produce hops that vary in time duration,
unlike the situation at Arecibo prior to the upgrade, when the hops all had the
same length.  Keith modified the reduction software to handle this... maybe
that's the source of the problem... the Bacchus and 1991 CS observations wouldn't
have been affected because I probably threw out incomplete hops, or perhaps 
because there were so few of them.  At any rate, perhaps that's where the 
error crept in.

Steve suggested that I compute the radar cross section directly from individual
hops without using rnb.cc.  Use raw spectra to estimate the background and the
echo.  I'll try that for 1999 GU3, 1999 JM8, and Mercury.  Mercury and JM8 will
be strong enough but I don't know if I'll be able to see echoes in individual
hops with the GU3 data. 

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

                        2000 February 23

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

Scott submitted the Golevka paper earlier this week, so I started asking him
again about JM8.  Although there's still work to do on the draft manuscript,
the shape model is the bottleneck at this point.  

I haven't prepared camera-ready figures yet either.  Some of those will
take a lot of time and may require learning IDL.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

/data/ast5/ is 96% full largely due to JM8 files.  There's 84 Meg of space
left (the partition holds 2.077 Gig).  

The JM8 files account for a lot of space:

reason:/data/ast5 < 374 > du -ks *
787367  1999JM8
10      4179_Toutatis_2000_arecibo
19      4179_Toutatis_2000_goldstone
601696  6489_Golevka
13409   delta
92208   hudson
47784   jx_src
2       lost+found
191634  ostro

Which JM8 files are taking up so much space?  

reason:/data/ast5/1999JM8 < 407 > du -ks *
1       README.TXT
1285    analysis
193     archives
151878  arecibo  <== These files are on /data/ast5/
850     html
1       paper
88189   proc
542865  raw      
2104    support

It's the raw imaging files...  Those files are all properly reduced and backed up
onto multiple CDroms and exabyte tapes, so let's remove them.  

I double checked that I backed up the raw files: YES.

Most of the raw VAX files are already gone.  The ones taking up all 
the space now are the unreduced rdf files created by running vax2rdf.
Have those files been backed up onto CDroms?  Many have, but not all:
I worked on some of those files in late November when I did the image
reductions correctly.  Find out which ones I have backed up onto CDroms
and then remove them.  Evidently I made minor modifications to several
files in November.  I'll back up those files onto CDroms during the next
iteration (as soon as Richard Zinar figures out what's wrong with the 
cd burner software).  Removing the other files liberated about 400 Meg.

Updated disk space:

reason:/data/ast5/1999JM8 < 508 > du -ks *
1       README.TXT
1285    analysis
193     archives
151878  arecibo
850     html
1       paper
88189   proc
127861  raw
2104    support

rhyme:/data/ast5     2077232 1369472  500040    74%    /data/ast5
rhyme:/data/ast6     2082712 1399504  474944    75%    /data/ast6

==> We're in pretty good shape now.  

Note: I need to make multiple backups of the Arecibo CBR data files--we
have only the one CDrom that Mike Nolan sent.  Once that's done, I'll remove
the Arecibo files.  

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

                        2000 March 1

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

I got backups onto CDroms to work again, so let's do that with the JM8
Arecibo data.  The Arecibo files take up 451 Meg of space.  Those are
the files in the raw directories.  The other JM8 files take up 372 Meg.

Burn, baby burn...

I'm making three disks: one for the office, one for myself to take home,
and one for Steve to take home.

...done.

I deleted the rdf files.  We have plenty of disk space on ../ast6:

reason:/data/ast6/1999JM8_arecibo < 118 > df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t1d0s0      31239   14178   13941    51%    /
/dev/dsk/c0t1d0s6     246167  192500   29057    87%    /usr
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
/dev/dsk/c0t1d0s4     246167   18321  203236     9%    /var
/dev/dsk/c0t1d0s7    1057078   59238  892140     7%    /export/apps0
/dev/dsk/c0t1d0s5      61735   11785   43780    22%    /opt
/dev/dsk/c0t1d0s3      61735       9   55556     1%    /usr/vice/cache
swap                  346416    1488  344928     1%    /tmp
/dev/dsk/c0t2d0s0     771110  438316  255684    64%    /usr/local/src
/dev/dsk/c0t2d0s1    2118718 1186912  719936    63%    /data/ast1
/dev/dsk/c0t2d0s3    2118718 1480278  426570    78%    /data/ast2
/dev/dsk/c0t2d0s4     963869  810119   57370    94%    /dev1
/dev/dsk/c0t2d0s6    2338501 1941488  163163    93%    /usr/local
rhyme:/data/ast4     2077232 1609848  259664    87%    /data/ast4
rhyme:/data/ast5     2077232 1373152  496360    74%    /data/ast5
rhyme:/data/ast6     2082712 1037072  837368    56%    /data/ast6        <==
rhyme:/cdmaster      1968608  315320 1456432    18%    /cdmaster
rhyme:/data/ast3     2077232 1621512  248000    87%    /data/ast3
rhyme:/export/home/ostro
                      874160  709656   77088    91%    /home/ostro
rhyme:/export/home/lance
                      874160  709656   77088    91%    /home/lance
rhyme:/export/home/wart
                      874160  709656   77088    91%    /home/wart

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

DOY 199 CW reduction revisited
==============================

Over the last two weeks I've done extensive tests of our CW reduction
software using noise background removal, polynomial background removal,
and estimating radar cross sections using raw hops.  The polynomial 
and raw hop reductions for Mercury give consistent results with each other
but both give radar cross sections that are 12-21% larger than the results
we get using noise background removal (the "regular" method).  Greg Black
suggested that there's a bug in our software but Steve doesn't fully 
believe it yet.  Meanwhile, Mike Thomas revised rnb.cc in the rdfreduc
pipeline to incorporate Greg's fix, but that fix isn't the default yet.

About two weeks ago (Feb 15) I reduced JM8 cw data and got weird noise
histograms.  The file was 99199b.  I used dofft with a 512 point FFT to
get lots of looks.  Unfortunately, that provides a relatively small number
of frequency bins (only about 128), so that could be the reason why the
histograms are off.  I want to to double check the histograms and also
check the results of different methods of noise removal on the radar
cross sections.

Use this file instead:

99199-16k    CW               4000      15            6   212119-213931

Go with a 4 k FFT => plenty of looks and plenty of Doppler bins.

That file does not exist as a VOLT file: recall that we started the expt.
with a 4 k FFT and then switched it on the fly to a 16 k FFT.  That produced
two PSD files but there's only 1 VOLT file with 4 kHz sampling:

VOLT99199.1999JM8

There are 7 runs total.  This didn't work the first time I tried: I forgot that
I had compressed the PRDX file.  dofft couldn't read it.

reason:/data/ast5/1999JM8/proc/cw < 104 > dofft -d 5.0 -p 163 -f 4096 -i VOLT99199.1999JM8 -o 99199.4k.raw.rdf -x PRDX.OUT.s15
contents of ast_spec control file:
4096,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199.1999JM8
RDFOUT_1=99199.4k.raw.1_1.rdf
RDFOUT_2=99199.4k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199.4k.raw.1.rdf -o 99199.4k.raw.rdf -x PRDX.OUT.s15  -p 163 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  627
Total SC spectra:  627
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 105 > 

So far, so good...

There are 627 FFTs.  As usual, irun values all equal one.  Rats.
There are a lot of hops too.  I wish Ray's software output hops instead of FFTs.

Run  spectra
---  -------
1     1- 91
2    92-180
3   181-268
4   269-358
5   359-448
6   449-538
7   539-627

I fixed all the irun values.  Printing out the rcsta values with enscript was a pain:
the top lines were truncated.  The option -P printer didn't work when I tried 
printing to lexmark.

Run this the rest of the way through the pipeline using noise background
removal...

Note: I haven't looked at individual hops yet.  That'll be a real pain but it can
be done: sum each hop.  The hops have different numbers of FFTs so the baselines
will jump around.  

Got rnb errors: rmsc is not what it should be, so rmsc was changed.  This is 
the problem that Greg Black has pointed out.  I want to repeat the reduction
using the "fixed" rnb.cc.

e/m values are very good for ch2 and pretty good for ch1: some are as low as 
0.4 but most exceed 0.9.

Ch1 = OC
Ch2 = SC

Individual runs look OK.  These echoes are probably strong enough to get 
cross sections from the hops.  

change jsnr1,2  = 510, 519

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-oc  21:37:57  00:00:00  21:39:31   0.0   2.56e-03   1.56e+00  3.7e-03  2.0
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-sc  21:37:57  00:00:00  21:39:31   0.0   2.78e-03   3.04e-01  3.9e-03  1.9 0.195498 0.198065 0.192933

OCxsec = 1.56e+00 km^2
SCxsec = 3.04e-01 km^2
SC/OC = 0.19

First pass at the noise histograms is very discouraging: they look horrible.
There are 627 looks so they should be OK, unless something is wrong with 
the data...  May need to check individual hops.  Rats.

Look over the tags again...maybe tau is wrong...No, maybe this is the effect
of the rnb problem.  That's the most obvious answer.  Steve agrees.
Why didn't we see this with Mercury?  Two hops...  What about 1991 CS?  those
observations used 4 hops (IBM data).

Try a polynomial reduction instead.  

Then try reducing one raw hop with lots of FFTs.  

Polynomial reduction
====================

Polynomial reduction uses rpb.cc, not rnb.cc, so I didn't get the error
messages.  

change jsnr1,2  = 510, 519

Sum runs; remove baseline with 4th order polynomial.

OC noise histogram looks weird: off centered.  It's possible that the big noise
spikes at both ends are distorting the noise distribution.  

Poly redn OC S/N is much higher: about 800 sigma vs. 400 sigma for rnb red'n.
Baseline isn't flat and there are some big noise spikes.  Zoom in to check:
Ugh.  Noise statistics won't work because background removal didn't produce
a flat baseline.  We can still extract cross sections, though.  

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.poly.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-oc  21:37:57  00:00:00  21:39:31   0.0   2.22e-03   2.72e+00  3.2e-03  2.0
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.poly.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-sc  21:37:57  00:00:00  21:39:31   0.0   2.41e-03   5.31e-01  3.4e-03  1.9 0.195112 0.196374 0.193851

OCxsec = 2.72e+00 km^2
SCxsec = 5.31e-01 km^2
SC/OC = 0.19

Notice how much larger the polynomial result is: they're in a ratio of 
2.72/1.56 = 1.74, which is very close to sqrt(3).  Damn.  Looks like Greg 
was right.  

The ratios are the same to two significant digits.

RAW HOP REDUCTION
=================

Sum a bunch of FFTs; don't remove baseline. 

Here are the first several hops:

rows    irun   xjcen
--------------------
   1     1.0   513.0
   2     1.0   513.0
   3     1.0   513.0
   4     1.0   513.0
   5     1.0   513.0
   6     1.0   513.0
   7     1.0  1537.0
   8     1.0  1537.0
   9     1.0  1537.0
  10     1.0  1537.0
  11     1.0  1537.0
  12     1.0  1537.0
  13     1.0  1537.0
  14     1.0  1537.0
  15     1.0  1537.0
  16     1.0  1537.0
  17     1.0  1537.0
  18     1.0  1537.0
  19     1.0  1537.0
  20     1.0  1537.0
  21     1.0  1537.0
  22     1.0  1537.0
  23     1.0  1537.0
  24     1.0  1537.0
  25     1.0  1537.0
  26     1.0  2561.0
  27     1.0  2561.0
  28     1.0  2561.0
  29     1.0  2561.0
  30     1.0  2561.0
  31     1.0  2561.0
  32     1.0  2561.0
  33     1.0  2561.0
  34     1.0  2561.0
  35     1.0  2561.0
  36     1.0  2561.0
  37     1.0  2561.0
  38     1.0  2561.0
  39     1.0  2561.0
  40     1.0  2561.0
  41     1.0  2561.0
  42     1.0  2561.0
  43     1.0  2561.0
  44     1.0  2561.0
  45     1.0  3585.0
  46     1.0  3585.0
  47     1.0  3585.0
  48     1.0  3585.0
  49     1.0  3585.0
  50     1.0  3585.0
  51     1.0  3585.0
  52     1.0  3585.0
  53     1.0  3585.0
  54     1.0  3585.0
  55     1.0  3585.0
  56     1.0  3585.0
  57     1.0  3585.0
  58     1.0  3585.0
  59     1.0  3585.0
  60     1.0  3585.0
  61     1.0  3585.0
  62     1.0  3585.0
  63     1.0  3585.0
  64     1.0   513.0
  65     1.0   513.0
  66     1.0   513.0
  67     1.0   513.0
  68     1.0   513.0
  69     1.0   513.0
  70     1.0   513.0
  71     1.0   513.0
  72     1.0   513.0
  73     1.0   513.0
  74     1.0   513.0
  75     1.0   513.0
  76     1.0   513.0
  77     1.0   513.0
  78     1.0   513.0
  79     1.0   513.0
  80     1.0   513.0
  81     1.0   513.0
  82     1.0   513.0
  83     1.0  1537.0
  84     1.0  1537.0
  85     1.0  1537.0
  86     1.0  1537.0
  87     1.0  1537.0
  88     1.0  1537.0
  89     1.0  1537.0
  90     1.0  1537.0
  91     1.0  1537.0

The 2nd hop looks fine: spectra 7-25.

background is at about 2.4e9 arbitrary units.

vignette by 1000 on left and 2000 bins on the right.

divide by 2.4e9 to locate the echo

Echo is between bins 536 and 541

use *vig* file to subtract 2.4e9 the sum the relevant points.

Oh, hell: there are only a handful--do it by hand.

Here they are:

rows            536            537            538            539            540            541
----------------------------------------------------------------------------------------------
   1      188440576     1608561408    18934968320    55651524608     7918448640      783266816

Sum = 8.51e10    (<== I double checked this)

Tsys = 15.2 (tag value; actual value was slightly different)

background = (2.4e9)*(6) = 1.44e10

E/B = 8.51e10/1.44e10 = 5.91

band = (6 bins)*(0.9766 Hz/bin) = 5.859 Hz

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(5.859 Hz)
     = 1.23e-21 W
 
Prcv = 5.91*(1.23E-21 W) = 7.26E-21 W

Prcv = Ptx*(G^2)*(lambda^2)*OCxsec/[((4*pi)^3)*(d^4)]

Or...

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

G^2 = 691.6E12
RTT = 99.7 s*(150 m/1E-6 s) = 1.50E10 m
Ptx = 425000 W

OCxsec = (7.26E-21 W)*(64*31)(1.50E10^4)/[425000*691.6E12*0.035*0.035]
       = 2.025E6 m^2
OR...    (2.025E6 m^2)*(1 km/1000 m)^2
       = 2.03 km^2

Unfortunately, this is intermediate between the polynomial reduction result (higher)
and the rnb result (lower).  Regardless, the rnb result is lower than both other
results.

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

                        2000 March 2, 3, & 5

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

The discrepancy between the raw hop redn and the polynomial redn is odd.  Steve
suggested summing all the ffts in each hop and then using the resulting spectra
to do the red'n.  

Hop FFTs
--- ----
1   1-6, 64-82, 92-95, 153-171, 203-221, 269-272, 330-348, 382-400, 449-451, 509-527, 560-578

2   7-25, 83-91, 96-114, 172-180, 222-240, 273-291, 349-358, 401-419, 452-470, 528-538, 579-597

3   26-44, 115-133, 181-183, 241-259, 292-310, 359-362, 420-438, 471-489, 539-540, 598-616

4   45-63, 134-152, 184-202, 260-268, 311-329, 363-381, 439-448, 490-508, 541-559, 617-627

Hop  FFTs
---  ----
1    146
2    171
3    142
4    168

Background levels are about 7e9 units; echoes are strongest in hops 2 and 4, 
which have the most spectra.  

background levels are about the same in both channels

Hop background
--- ----------
1
2   6.8e9
3
4

=====
Hop 2
=====

hop 2 normalized by 6.8e9:

rows  1536  1537  1538  1539  1540  1541  1542
----------------------------------------------
   1  1.32  1.94  8.74 35.67  3.86  1.56  1.16

rows  1536  1537  1538  1539  1540  1541  1542
----------------------------------------------
   1  1.01  1.17  2.64  7.91  1.60  1.18  1.01

Use points 1538-1540.

Unnormalized:

rows         1536         1537         1538         1539         1540         1541         1542
-----------------------------------------------------------------------------------------------
   1   8961508352  13209784320  59429937152 242577473536  26246967296  10636954624   7880826880

rows         1536         1537         1538         1539         1540         1541         1542
-----------------------------------------------------------------------------------------------
   1   6839524352   7946156544  17976283136  53762555904  10866804736   7997476352   6854330368

OC Echo
points 1538-1540: 59429937152 + 242577473536 + 26246967296 = 3.28e11

background = (3 points)*(6.8e9) = 2.04e10

bandwidth = (3 bins)*(0.97656 Hz/point) = 2.93 Hz

E/B = 3.28e11/2.04e10 = 16.08

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(2.93 Hz)
     = 6.15e-22 W
 
Prcv = 16.08*(6.15E-22 W) = 9.88E-21 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

Tsys = 15.2
G^2 = 689.3E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

OCxsec = (9.88E-21 W)*(64*31)(1.494E10^4)/[425000*689.3E12*0.035*0.035]
       = 2.72E6 m^2
OR...    (2.72E6 m^2)*(1 km/1000 m)^2
       = 2.72 km^2

That matches the result from the polynomial reduction, as it should.

=====
HOP 4
=====

Tsys = 15.2
G^2 = 689.2E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

Divide by 6.8E9.  Here's the echo:

rows  3584  3585  3586  3587  3588  3589
----------------------------------------
   1  1.47  2.30 18.37 34.44  3.30  1.65

rows  3584  3585  3586  3587  3588  3589
----------------------------------------
   1  1.25  1.27  3.21  6.50  1.14  1.14

Use points between 3585-3588

rows         3584         3585         3586         3587         3588         3589
----------------------------------------------------------------------------------
   1   9985381376  15615210496 124892807168 234168320000  22466283520  11243105280

rows         3584         3585         3586         3587         3588         3589
----------------------------------------------------------------------------------
   1   8490705920   8603100160  21807790080  44211630080   7760810496   7754109952

Echo: 124892807168 + 234168320000 = 3.59e11

background = (2)*(6.8e9) = 1.36e10

E/B = 3.59e11/1.36e10 = 26.4

band = 2*0.976 Hz/bin = 1.953 Hz

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(1.953 Hz)
     = 4.10-22 W
 
Prcv = 26.4*(4.10E-22 W) = 1.08E-20 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

OCxsec = (1.08E-20 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035]
       = 2.98E6 m^2
       = 2.98 km^2

That's about 10% higher than the result I get with hop 2

=====
HOP 1
=====

Tsys = 15.2
G^2 = 690.3E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

Divide by 6.8e9: background average is unity.

rows   512   513   514   515   516   517
----------------------------------------
   1  1.28  2.14 12.25 33.69  3.08  1.32

rows   512   513   514   515   516   517
----------------------------------------
   1  1.08  1.21  3.01  7.16  1.38  0.98

Echo is between 514 and 516

rows           514           515           516
----------------------------------------------
   1   83303587840  229058674688   20972343296 = 3.33e11

rows           514           515           516
----------------------------------------------
   1   20497252352   48655515648    9400629248

background = 3(6.8e9) = 2.04e10
E/B = 3.33e11/2.04e10 = 16.34

band = 2.93 Hz

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(2.93 Hz)
     = 6.15e-22 W
 
Prcv = 16.34*(6.15E-22 W) = 1.00E-20 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

OCxsec = (1.00E-20 W)*(64*31)(1.494E10^4)/[425000*690.3E12*0.035*0.035]
       = 2.76E6 m^2
       = 2.76 km^2

Good match.

=====
HOP 3
=====

Tsys = 15.2
G^2 = 689.2E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

Notice how the gain varies from hop to hop.  It shouldn't. 

background is at about 6.8e9.

Divide by 6.8e9:

rows  2561  2562  2563  2564
----------------------------
   1  2.18 18.29 27.86  2.51

rows  2561  2562  2563  2564
----------------------------
   1  1.00  3.34  5.22  1.14

Echo is between 2652-2563

rows          2562          2563
--------------------------------
   1  124353404928  189436493824 = 3.138e11

rows          2562          2563
--------------------------------
   1   22712643584   35468017664

background = 2*(6.8e9) = 1.36e10
E/B = 3.14e11/1.36e10 = 23.1

band = 2*(0.978) = 1.953 Hz

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(1.953 Hz)
     = 4.10e-22 W
 
Prcv = 23.1*(4.10E-22 W) = 9.46E-21 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

OCxsec = (9.46E-21 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035]
       = 2.61E6 m^2
       = 2.61 km^2

Summary

Hop  FFTs  OCxsec km^2  
---  ----  -----------
1    146   2.76
2    171   2.72
3    142   2.61
4    168   2.98

These results are consistent with the polynomial reduction but are inconsistent
with the regular noise background removal.  Greg Black is right.

The reason the gains vary from hop to hop is because the gains vary due to
the telescope's elevation and pointing.  Recall that the hops span 7 runs
when the asteroid had a RTT of nearly 100 seconds--so the dish moved appreciably
during that interval.  However, the gain that appeared in the tags was the 
*first* one for a given hop.  This probably also accounts for minor differences
in the cross sections.

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

                        2000 March 6 & 7

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

Now that we know the old "regular" cross sections are wrong, go back to the 
CW data and repeat the reductions using the new rnb software.  As a check, 
do the reductions using the hops too.  

----------------------------------------------------------------------------
Check two-hop data as well: there shouldn't be any change but it's worth
finding out.  The difference between regular background removal and using
the raw hops with 2 frequencies is puzzling.
----------------------------------------------------------------------------

I tried Mike Thomas' fix to rnb but it didn't work: the software looked for 
the other reduction programs in the wrong directory.  I sent Mike email and
he fixed it.  Try it again:

/dev1/wart/bin/tkrdfreduc 

This time the reduction worked.  e/m values are MUCH better: Ch2 (SC) are 
all close to unity (the smallest is about 0.85).  Ch1 are better, but there
are still some with values as low as about 0.28, although far fewer than 
with the old version of the software.  Interesting...

Spectra look pretty good.  OC echoes are between 250 and 300 sigma. 

Each spectrum has about 90 FFTs, so the noise in each should be close to
Gaussian.  

The noise OC noise statistics for spectra 1-6 look fine, but something is
wrong with spectrum 7: I get one huge spike with unphysical limits on 
the horizontal axis.  That's odd: the OC spectrum looks OK.  OK: there's
no problem--I forgot that the noise plotting is zero based, where the other
tkpl filters are 1-based.  That is, plot noise for spectra 0-6, not 1-7.
Duh.  Noise for spectrum 7 is rubbish because there IS no spectrum 7.

recall that dfreq = 0.98 Hz

Summed spectra has raw OC S/N of about 700.  The noise histogram is MUCH
better, but it's still not perfect: there appears to be an excess of ~4 
sigma points.  Perhaps that's (sincx/x)^2?  The distribution still looks
a bit skewed despite having about 

Note: the summed spectrum has about 630 FFTs, but the tag on the summed file 
indicates only 89 FFTs.  That value wasn't summed.  

I changed jsnr2 -> 520.  

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.new.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-oc  21:37:57  00:00:00  21:39:31   0.0   2.56e-03   2.87e+00  3.7e-03  2.1
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.new.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-sc  21:37:57  00:00:00  21:39:31   0.0   2.78e-03   5.59e-01  3.9e-03  2.0 0.195131 0.196531 0.193731

OCxsec = 2.87 km^2
SCxsec = 0.56 km^2
SC/OC = 0.20

This is comparable to the raw hop and polynomial results: 2.72 km^2.  The 
difference is about 5.5%, which is fine.

Note: I did not correct Tsys to the correct values--for now, I'm just comparing
results obtained using the different methods of reduction.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Repeat the reduction by blocking into a file.  
=============================================

output file: 99199.4k.file.new.rdf

e/m comparable to last time.

this time the # ffts is correct: 627.

The histogram looks better: there was a slight mismatch with blocking
into runs but not with blocking into a file.

- - - - - - - - - - -

Mike Thomas installed the new version of tkrdfreduc on the Goldstone
computers but he's had trouble doing that at Arecibo: he gets bumped
off the system as soon as he logs in.  I had that problem about a year
ago and I had to get Arun to correct it. 

==> REPEAT THE REDUCTIONS USING NEW SOFTWARE AND CORRECT TSYS VALUES <== 

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

                        2000 April 7, 10, & 11

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

We got CW data with 4 hops on the first three days: DOY 199/200, 201, and 202.
All the other CW data used two hops.

DOY 199/200
===========

I've already done most of the work.  Fix the Tsys tags and then repeat
the noise background removal and raw hop reductions.

Do this to the raw corrected data file and to each of the four hopsum
files.  For Tsys, use either the value on point just before we started,
or use an average of Tsys measured (the values dropped as the elevation
increased).

Use the summed, raw hops.  

Average Tsys

Ch1 = 15.53 <== Not recorded; used difference on point just before start of 1st run
Ch2 = 17.35

I fixed Tsys for each channel in the files:

99199.4k.hop1sum.rdf
99199.4k.hop2sum.rdf
99199.4k.hop3sum.rdf
99199.4k.hop4sum.rdf

This won't change the cross sections very much.  

Here are salient excerpts from the earlier reduction (early March):

=====
HOP 1
=====

Tsys Ch1 = 15.5
     Ch2 = 17.4
G^2 = 690.3E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

Divide by 6.8e9: background average is unity.

rows   512   513   514   515   516   517
----------------------------------------
   1  1.28  2.14 12.25 33.69  3.08  1.32

rows   512   513   514   515   516   517
----------------------------------------
   1  1.08  1.21  3.01  7.16  1.38  0.98

Echo is between 514 and 516

rows           514           515           516
----------------------------------------------
   1   83303587840  229058674688   20972343296 = 3.33e11

rows           514           515           516
----------------------------------------------
   1   20497252352   48655515648    9400629248

background = 3(6.8e9) = 2.04e10
E/B = 3.33e11/2.04e10 = 16.34

band = 2.93 Hz

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.5 K)*(2.93 Hz)
     = 6.27e-22 W
 
Prcv = 16.34*(6.27E-22 W) = 1.024E-20 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

OCxsec = (1.024E-20 W)*(64*31)(1.494E10^4)/[425000*690.3E12*0.035*0.035]
       = 2.817E6 m^2
       = 2.82 km^2

=====
Hop 2
=====

hop 2 normalized by 6.8e9:

rows  1536  1537  1538  1539  1540  1541  1542
----------------------------------------------
   1  1.32  1.94  8.74 35.67  3.86  1.56  1.16

rows  1536  1537  1538  1539  1540  1541  1542
----------------------------------------------
   1  1.01  1.17  2.64  7.91  1.60  1.18  1.01

Use points 1538-1540.

Unnormalized:

rows         1536         1537         1538         1539         1540         1541         1542
-----------------------------------------------------------------------------------------------
   1   8961508352  13209784320  59429937152 242577473536  26246967296  10636954624   7880826880

rows         1536         1537         1538         1539         1540         1541         1542
-----------------------------------------------------------------------------------------------
   1   6839524352   7946156544  17976283136  53762555904  10866804736   7997476352   6854330368

OC Echo
points 1538-1540: 59429937152 + 242577473536 + 26246967296 = 3.28e11

background = (3 points)*(6.8e9) = 2.04e10

bandwidth = (3 bins)*(0.97656 Hz/point) = 2.93 Hz

E/B = 3.28e11/2.04e10 = 16.08

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.5 K)*(2.93 Hz)
     = 6.27e-22 W
 
Prcv = 16.08*(6.27E-22 W) = 1.01E-20 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

Tsys = 15.5
G^2 = 689.3E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

OCxsec = (1.01E-21 W)*(64*31)(1.494E10^4)/[425000*689.3E12*0.035*0.035]
       = 2.78E6 m^2
OR...    (2.78E6 m^2)*(1 km/1000 m)^2
       = 2.78 km^2

=====
HOP 3
=====

Tsys = 15.5
G^2 = 689.2E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

background is at about 6.8e9.

Divide by 6.8e9:

rows  2561  2562  2563  2564
----------------------------
   1  2.18 18.29 27.86  2.51

rows  2561  2562  2563  2564
----------------------------
   1  1.00  3.34  5.22  1.14

Echo is between 2652-2563

rows          2562          2563
--------------------------------
   1  124353404928  189436493824 = 3.138e11

rows          2562          2563
--------------------------------
   1   22712643584   35468017664

background = 2*(6.8e9) = 1.36e10
E/B = 3.14e11/1.36e10 = 23.1

band = 2*(0.978) = 1.953 Hz

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.5 K)*(1.953 Hz)
     = 4.18e-22 W
 
Prcv = 23.1*(4.18E-22 W) = 9.65E-21 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

OCxsec = (9.65E-21 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035]
       = 2.66E6 m^2
       = 2.66 km^2

=====
HOP 4
=====

Tsys = 15.5
G^2 = 689.2E12
RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m
Ptx = 425000 W

Divide by 6.8E9.  Here's the echo:

rows  3584  3585  3586  3587  3588  3589
----------------------------------------
   1  1.47  2.30 18.37 34.44  3.30  1.65

rows  3584  3585  3586  3587  3588  3589
----------------------------------------
   1  1.25  1.27  3.21  6.50  1.14  1.14

Use points between 3585-3588

rows         3584         3585         3586         3587         3588         3589
----------------------------------------------------------------------------------
   1   9985381376  15615210496 124892807168 234168320000  22466283520  11243105280

rows         3584         3585         3586         3587         3588         3589
----------------------------------------------------------------------------------
   1   8490705920   8603100160  21807790080  44211630080   7760810496   7754109952

Echo: 124892807168 + 234168320000 = 3.59e11

background = (2)*(6.8e9) = 1.36e10

E/B = 3.59e11/1.36e10 = 26.4

band = 2*0.976 Hz/bin = 1.953 Hz

base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(1.953 Hz)
     = 4.18-22 W
 
Prcv = 26.4*(4.18E-22 W) = 1.10E-20 W

OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)]

OCxsec = (1.10E-20 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035]
       = 3.03E6 m^2
       = 3.03 km^2

SUMMARY
=======
Hop  FFTs  OCxsec km^2   SCxsec km^2
---  ----  -----------   -----------
1    146     2.82        
2    171     2.78        
3    142     2.66        
4    168     3.03        

Mean         2.82         

This was more effort than it was worth: use noise background removal for the
other days.

I changed Tsys in the file: 99199.4k.raw.corrected.rdf and then I ran it
through the reduction pipeline using the corrected version of rnb.

There weren't any obvious reduction problems.  e/m for SC was somewhat
better than for OC.  Might this be related to jsnr1 and 2 being set 
incorrectly and the stronger OC echoes?  ...It's plausible because 
jsnr2 is within a very strong echo.  

jsnr1,2 = 511, 514

rows    505    506    507    508    509    510    511    512    513    514    515    516    517    518    519    520
--------------------------------------------------------------------------------------------------------------------
   1  -0.29   3.45   2.11   3.26   2.88   2.40   3.78   9.20  27.32 298.18 692.75  47.81   8.37   5.18   3.15   1.98

rows    505    506    507    508    509    510    511    512    513    514    515    516    517    518    519    520
--------------------------------------------------------------------------------------------------------------------
   1  -1.09  -1.12   1.39   1.53  -1.36   1.40   0.35   3.60   4.23  45.97 130.07   7.50   2.55   1.26   0.21  -0.61

Change jsnr1,2 = 509, 519.  

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.file.new.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-oc  21:14:33  00:00:00  21:39:31   0.0   2.62e-03   2.89e+00  3.8e-03  2.1
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.file.new.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   7-sc  21:14:33  00:00:00  21:39:31   0.0   2.93e-03   5.73e-01  4.1e-03  2.0 0.198645 0.200106 0.197186

OCxsec = 2.89 km^2
SCxsec = 0.57 km^2
SC/OC = 0.20+/-0.01

I played around with frequency smoothing to produce the maximum S/N.  To my
surprise, the optimal value is about dreq = 1.6 Hz.  Differences of only 0.1 Hz
produce significant differences in the SNR:
  
dfreq OC S/N
----- ------
1.0    692
1.4    829
1.5    858
1.6    886
1.7    734

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

file 99199B (DOY 200; July 19)
------------------------------

99199B.nocal.512.corrected.rdf

These data have 484 looks.  Tsys has already been set but irun hasn't (not that
it really matters if I'm going to block into a file anyway).  dfreq = 1.95 Hz.
We got this file during the same track as file 99199, but in the interim we 
observed 1999 NW2, we tried to fix a problem with ranging, and we crossed the
threshold from DOY 199 -> 200.  There are only 3 runs.  

Use the existing file to get OCxsec and SC/OC and then go back with a 1024-point
FFT to get 0.98 Hz resolution to maintain consistency with file 99199.  

As expected, the bandwidths between the two files on this track are consistent.

Tsys values are close enough that I'm not going to change them.

rows     60     61     62     63     64     65     66     67     68     69     70   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1  -0.16   1.08   0.18   1.16   3.16  15.48 129.78   4.05   2.47   1.47   0.30    64.0    67.0

rows     60     61     62     63     64     65     66     67     68     69     70   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   1.13   0.92   0.77   0.57   0.80   1.90  19.12  -0.07   0.69  -0.22   0.40    64.0    67.0

jsnr1 and 2 should be fine, although it would be better if they were a 
couple of bins wider.

Use the nocal.corrected file to block into a file.

reduction seems to have gone smoothly.

change jsnr1,2 = 63, 69

dfreq OC SNR
----- ------  
1.95   238

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199B.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-oc  07:06:05  00:00:00  07:14:08   0.0   7.49e-03   2.16e+00  9.0e-03  2.8
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199B.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-sc  07:06:05  00:00:00  07:14:08   0.0   7.89e-03   3.30e-01  9.3e-03  2.7 0.152532 0.156903 0.148166

OCxsec = 2.16 km^2
SC/OC = 0.15+/-0.01

These results differ significantly from what I got with file 99199.  
Given that JM8 barely rotated during the interim, this clearly justifies our
adoption of large uncertainties.  The telescope's elevation was much lower 
(25 deg vs about 52) and the system Temps were almost 4 degrees hotter, an 
increase of about 22%.  The gain was down by about 5.6% too.

The peak S/N in the new figure is substantially higher than in the old figure,
as it should be (recall the discussion with Greg Black).  

Do a quick pass with a 1024 point FFT to get 0.98 Hz resolution:

reason:/data/ast5/1999JM8/proc/cw < 18 > dofft -d 5.0 -p 162 -f 1024 -i VOLT99199B-8k.1999JM8 -o 99199B.1k.raw.rdf -x PRDX.OUT.s15 
contents of ast_spec control file:
1024,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199B-8k.1999JM8
RDFOUT_1=99199B.1k.raw.1_1.rdf
RDFOUT_2=99199B.1k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199B.1k.raw.1.rdf -o 99199B.1k.raw.rdf -x PRDX.OUT.s15  -p 162 -d 5.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  242
Total SC spectra:  242
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 19 > 

dfreq = 0.98 Hz.  242 FFTs.  leave irun = 1.

The OC reduction output looks a bit strange: some of it is out of order.  Is there
something wrong with the file?  I checked the first 4 hops in each channel: they
don't look right--the echoes should jump out above the noise but they don't.  Very
strong chi-sq effects are evident.  The reduced spectrum looks OK, though.  
Signal is present in many of the individual hops but in some the signal is lost in
the noise.    I don't understand this.  I repeated the reduction
just in case the output the first time was a fluke, but the output was the same.
I haven't seen this before so I'm going to ignore the results from this file.

I checked the first 40 OC hops from file 99199 (as above) and found similar
spectra, but in general the echoes were easier to see in most hops.  Part of
the variation at echo-containing frequencies could be self noise, which is
at a maximum with only 1 look/spectrum.

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

99201
=====

99201.512.nocal.corrected.rdf

512 FFT => 1.95 Hz/bin.  2 runs, 308 hops.  

Tsys  Ch1 = 15.9 K
      Ch2 = 16.8 K

Those are good values.  They were taken from the electronic logfile.
irun = 1, which is fine because I'm going to block into a file.
Will probably need to adjust jsnr1 and 2.

Run through the new version of rnb:

I get the same out-of-sequence output with this file that I did before.
What's happening is that the blocking report for SC is being output
before rnb for OC has finished.  Perhaps they're running in parallel? 
Or is this a bug?  Let's check with the old version of rnb...
It happens with the old software too.  What if we block into runs?
Duh...irun = 1 so everything will be blocked into a file anyway.
==> The output came out in the sequence that I've always seen before.
Interesting...  So, is this significant?  Since I didn't adjust irun,
the output should be the same for blocking by file and by runs
in this case.  Let's check.

==> The results seem to be identical as far as I can tell.  I checked
the echo points, did t87 listings, made plots of both spectra, checked
the tags, and noise histograms.  

Still need to do a t87 listing etc.  

rows     60     61     62     63     64     65     66     67     68     69     70   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   4.22   0.98   4.08  12.55  98.47 376.17  13.56   5.38   2.63   0.31   0.92    64.0    65.0

rows     60     61     62     63     64     65     66     67     68     69     70   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   1.55   1.07   0.59   2.77  20.79  63.72   2.78   0.09   1.01   0.24   0.18    64.0    65.0

Change jsnr1,2 = 61,69.  That includes the impulse response but it's
weak enough that it doesn't contribute much.

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-oc  02:31:56  00:00:00  02:36:32   0.0   5.77e-03   2.97e+00  7.6e-03  3.4
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-sc  02:31:56  00:00:00  02:36:32   0.0   6.08e-03   5.66e-01  8.4e-03  3.8 0.190686 0.193568 0.187806

OCxsec = 2.97 km^2  <== Previously I got 1.6 km^2
SCxsec = 0.57 km^2
SC/OC = 0.19+/-0.01

Crank through a quick reduction using a 1k FFT to get 0.98-Hz resolution:
=========================================================================

reason:/data/ast5/1999JM8/proc/cw < 13 > dofft -d 5 -p 162 -f 1024 -i VOLT99201.1999JM8 -o 99201.1k.raw.rdf -x PRDX.OUT.s17 
contents of ast_spec control file:
1024,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99201.1999JM8
RDFOUT_1=99201.1k.raw.1_1.rdf
RDFOUT_2=99201.1k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99201.1k.raw.1.rdf -o 99201.1k.raw.rdf -x PRDX.OUT.s17  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  154
Total SC spectra:  154
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 14 >

These data sampled slowly enough that this takes only a few seconds. 

Change Tsys to: 
Tsys  Ch1 = 15.9 K
      Ch2 = 16.8 K

I looked at all the OC hops (1 FFT/hop).  Occasionally the echo
appears in the correct hop and in the "next" hop in the sequence.
That could be skewing some of the noise statistics and may partially
account for the difference in e/m values that I see when I'm reducing
OC and SC spectra.  

leave irun = 1 and block into runs (effectively 1 run).

Reduction looks good.

rows    123    124    125    126    127    128    129    130    131    132    133   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   0.30   2.68   3.04   5.34  23.91 327.66 333.91  25.00   5.07   4.04   1.82   127.0   130.0

rows    123    124    125    126    127    128    129    130    131    132    133   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1  -0.43   0.47   3.04   0.61   7.98  56.43  58.35   2.53   1.85   0.20  -0.10   127.0   130.0

change jsnr1,2 = 125,132
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.1k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-oc  02:31:56  00:00:00  02:36:32   0.0   4.08e-03   2.97e+00  6.3e-03  2.4
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.1k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/20   1-sc  02:31:56  00:00:00  02:36:32   0.0   4.31e-03   5.64e-01  6.9e-03  2.5 0.190132 0.192495 0.18777

As expected, this didn't make much difference with the cross sections.

Now use the finer freq res'n to estimate the peak S/N:

dfreq  S/N
-----  ---
0.98   334
1.5    414
1.6    427
1.7    385
1.95   376

Check the noise statistics: pretty good, although there seems to be an excess of 
points at about +0.5 sigma when using more than about 20 histogram bins (there 
are 256 points).  If I use fewer points then the histogram is closer to
Gaussian but obviously the resolution is worse.  Good thing I didn't sample
any more slowly than 1 kHz.  

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

file 99202
==========

I did only 1 cw run on DOY202.  In the future, do at least 3 on those
days when I decide to do any.  5 would be even better if there's time,
just in case some runs are bad and to get better noise statistics.

I'm not going to bother looking at the 512 point FFT data.  Go right to
a 1 k FFT:

reason:/data/ast5/1999JM8/proc/cw < 29 > dofft -d 5 -p 163 -f 1024 -i VOLT99202.1999JM8 -o 99202.1k.raw.rdf -x PRDX.OUT.s19
contents of ast_spec control file:
1024,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99202.1999JM8
RDFOUT_1=99202.1k.raw.1_1.rdf
RDFOUT_2=99202.1k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99202.1k.raw.1.rdf -o 99202.1k.raw.rdf -x PRDX.OUT.s19  -p 163 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  70
Total SC spectra:  70
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 30 > 

There are 70 hops.

Set Tsys as follows:
Ch1 = 17.79 K
Ch2 = 18.85 K

The individual OC hops look OK (I checked all 70).

No obvious problems with the reduction.

Peak S/N:

dfreq  S/N
-----  ---
0.98   623
1.4    746
1.5    772
1.6    798
1.7    641  !  Rather large change given the modest increase in the filtering...

rows    123    124    125    126    127    128    129    130    131    132    133    134    135    136   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1   2.09   1.59   2.53   4.76   4.11  12.07 179.95 623.46  25.12   8.24   3.53   2.06  -0.17   1.30   127.0   130.0

rows    123    124    125    126    127    128    129    130    131    132    133    134    135    136   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1   1.46  -1.22   0.57  -1.77   2.13   1.25  57.72  95.47   5.94   4.02   0.95   2.30  -0.60  -0.50   127.0   130.0

change jsnr1,2 = 125,134

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.1k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-oc  17:41:37  00:00:00  17:42:56   0.0   4.61e-03   3.99e+00  6.1e-03  1.7
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.1k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-sc  17:41:37  00:00:00  17:42:56   0.0   4.89e-03   8.24e-01  7.4e-03  2.2 0.206307 0.208179 0.204436

Wow!  

OCxsec = 3.99 km^2
SCxsec = 0.82 km^2
SC/OC = 0.21 +/-0.01

This cross section is about 25% larger than what we got on the previous day
and it's also the largest of the three days (DOY 199, 201, and 202).

This would be worth double checking using raw hops and with coarser frequency
resolution.   

Check the noise statistics...  there's a discernible positive skew to the
distributions in both the OC and SC histograms.  

Check the cross sections and ratio using a 512-point FFT:

Tsys values are set as follows:
Ch1 = 17.8
Ch2 = 19.0

They're close enough to the "real" values that I'm not going to change 
them.  

I didn't change any of the tags in file 99202.512.nocal.corrected.rdf

The blocking report and rnb output between OC and SC are interleaved again
and the usual e/m discrepancy between OC and SC is present, but there are
no obvious show stoppers with the reduction.

rows     60     61     62     63     64     65     66     67     68     69     70   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   1.64   0.14   6.67   8.83  19.22 307.35 170.45  18.13   5.52   5.74  -0.09    64.0    65.0

rows     60     61     62     63     64     65     66     67     68     69     70   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   2.16  -0.38  -0.01   0.22   3.71  70.91  30.27   4.04  -0.32   0.57   1.69    64.0    65.0

Change jsnr1,2 = 61,70

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-oc  17:41:37  00:00:00  17:42:56   0.0   6.52e-03   3.54e+00  1.0e-02  4.6
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/21   1-sc  17:41:37  00:00:00  17:42:56   0.0   6.96e-03   7.71e-01  1.0e-02  4.0 0.217995 0.220883 0.21511

OCxsec = 3.54 km^2
SCxsec = 0.77 km^2
SC/OC = 0.22+/-0.01

The ratio is very similar to what I got with a 1k FFT (0.21) but 
OCxec is 11% smaller.  ==> Quote uncertainties of at least 25%.

Check the noise statistics:

This may not work well because there are only 128 points...
actually, it worked better than expected.  The noise is closer
to Gaussian than it was with only 70 hops, as it should be, but
there's still an excess of positive points.

Lessons: 
1. Use enough FFTs to get good noise statistics
2. Take enough runs to get good noise statistics over a range of 
   desirable frequency resolutions.  In this case one or two more runs would
   have sufficed.  

However, this was a very short track: The observations span just over 1 hour,
so my decision to take only one CW run was justified because we wanted to
maximize the number of imaging runs.  The main reason I did _any_ cw runs was
to verify that we had echoes and to check that the ephemeris was OK.

Question: which cross sections should we use?  Let's go with the ones obtained
using 140 looks (1.95-Hz resolution).  To maintain consistency, use the same 
frequency resolution for all the cross sections and ratios.  Fortunately the
results were consistent using 0.98 Hz resn and 1.95 Hz resn on DOY 201.  
I didn't work with 1.95 Hz spectra on DOY 199, though.  

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

Return to 99199: use a 2 k FFT
==============================

reason:/data/ast5/1999JM8/proc/cw < 45 > dofft -d 5 -p 162 -f 2048 -i VOLT99199.1999JM8 -o 99199.2k.raw.rdf -x PRDX.OUT.s15 
contents of ast_spec control file:
2048,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199.1999JM8
RDFOUT_1=99199.2k.raw.1_1.rdf
RDFOUT_2=99199.2k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199.2k.raw.1.rdf -o 99199.2k.raw.rdf -x PRDX.OUT.s15  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  1270
Total SC spectra:  1270
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 46 > 

Adopt the same temperatures that we used with the 4k FFT file:

rows    tsys
------------
   1    15.5

rows    tsys
------------
   1    17.4

There are 1270 looks.

Complete the reduction...

...looks OK.  Usual e/m discrepancy and the interleaving of the blocking
reports and rnb output.

There are so many hops that I'm not going to check them all.  Let's go
straight to the spectrum, set jsnr1 and 2, and get the cross sections.

rows    253    254    255    256    257    258    259    260    261    262    263   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   0.96   5.31   3.53   6.09  52.60 713.74  14.33   4.52   2.65   2.41   1.07   256.0   257.0

rows    253    254    255    256    257    258    259    260    261    262    263   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1  -0.94   0.87  -0.43   1.62   9.54 124.33   3.44   0.71  -0.52  -1.38  -1.19   256.0   257.0

change jsnr1,2 = 253, 261

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.2k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   1-oc  21:14:33  00:00:00  21:39:31   0.0   3.68e-03   2.96e+00  4.1e-03  2.5
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.2k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/18   1-sc  21:14:33  00:00:00  21:39:31   0.0   4.12e-03   5.71e-01  4.6e-03  2.4 0.193051 0.194622 0.191481

OCxsec = 2.96 km^2  (before we got 2.89 km^2)
SCxsec = 0.57 km^2  
SC/OC = 0.19        (before we got 0.20)

==> Consistent with earlier results.

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

99204
=====

We already have a raw file with 1.95 Hz resolution.  

According to the notebook, Tsys ch 1 = 16.2, ch2 = 16.7

This was another very short track so I did only one CW run.
The observations span about 1 hour.  

Existing Tsys tags use values from zenith, so change them to
those above.

reduction proceeded normally.

only 132 FFTs.  RTT was decreasing from day to day.

Spectral shape is almost identical but the peak S/N is about
30 sigma higher than it was with the old reduction using the
old rnb software.  

rows    123    124    125    126    127    128    129    130    131    132    133   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1  -0.51   1.57   0.40   0.96   2.50   5.55 391.88  27.89   7.20   3.06   0.45   128.0   129.0

rows    123    124    125    126    127    128    129    130    131    132    133   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   2.80   1.01  -0.77   0.29   0.04   1.51  62.82   4.48   1.14  -0.65   0.73   128.0   129.0

change jsnr1,2 = 127, 132

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-oc  00:36:50  00:00:00  00:38:01   0.0   5.16e-03   2.26e+00  5.8e-03  2.4
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-sc  00:36:50  00:00:00  00:38:01   0.0   5.32e-03   3.69e-01  5.9e-03  2.4 0.163147 0.165771 0.160526

OCxsec = 2.26 km^2
SCxsec = 0.37 km^2
SC/OC =  0.16+/-0.01

This result is only about 10% larger than my earlier estimate using the
old version of rnb.cc.  What I don't understand is why there's any difference.
Did Mike Thomas change something else when he installed the fix?  

What's really interesting is that this represents a 36% decrease
relative to the cross section that we got about 31 hours earlier
on July 21 (DOY 202).  Recall that the echo on DOY 204 was rather
limited--perhaps we were seeing an "end-on" phase?

Noise statistics are pretty close to Gaussian.

Do a quick 0.98-Hz resn red'n to get the optimal frequency smoothing.
---------------------------------------------------------------------

reason:/data/ast5/1999JM8/proc/cw < 63 > dofft -d 5 -p 162 -f 1024 -i VOLT99204.1999JM8 -o 99204.1k.raw.rdf -x PRDX.OUT.s21 
contents of ast_spec control file:
1024,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99204.1999JM8
RDFOUT_1=99204.1k.raw.1_1.rdf
RDFOUT_2=99204.1k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99204.1k.raw.1.rdf -o 99204.1k.raw.rdf -x PRDX.OUT.s21  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  66
Total SC spectra:  66
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 64 > 

It seems that the VME operator set Tsys because the values
I corrected before are already tagged on the VOLT data.  

Change them to: ch1 = 16.22, ch2 = 16.72

There are only 65 looks.  Interestingly, the e/m values are the worst that
I've seen thus far in all the JM8 cw data that I've reduced in the last 
couple of days.  Coincidence?  JM8 was closer on this day than on the
others so the echoes were much stronger.  There may have been more 
"bleeding" of hops during each FFT than before...

rows    250    251    252    253    254    255    256    257    258    259    260   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1  -0.22   1.03   0.68   0.91   4.30   3.64  19.52 439.33 122.57  10.73   3.11   255.0   258.0

rows    250    251    252    253    254    255    256    257    258    259    260   jsnr1   jsnr2
-------------------------------------------------------------------------------------------------
   1   0.39  -0.13   0.29  -0.78   1.76   0.23   2.46  63.18  29.50   1.70   0.71   255.0   258.0

change jsnr1,2 -> 253, 260

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.1k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-oc  00:36:50  00:00:00  00:38:01   0.0   3.65e-03   2.20e+00  4.8e-03  1.7
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.1k.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/23   1-sc  00:36:50  00:00:00  00:38:01   0.0   3.76e-03   3.71e-01  5.3e-03  2.0 0.168524 0.170966 0.166083

Despite having only 65 looks, these results are very similar to what I
got with twice that number.  

dfreq OC S/N
----- ------
0.98   439
1.5    544
1.6    562
1.7    451  <== That huge decrease again... Odd.  I plotted the last two
spectra to verify that it's real...and it is.  Think about this some more
and ask Steve.  Something wrong with the smoothing software?  Or is there
something fundamental about smoothing that I don't realize?  What's happening
is that a little bit of smoothing, say from 1.6 Hz to 1.7 Hz, spreads a lot
of the power in the peak Doppler bin (where most of the power is) into the
two adjacent bins, so the peak drops significantly.  My guess is that if
I used a longer FFT to get finer resolution and then filtered the resulting
spectrum that I would see a more gradual transition in the peak S/N as I used
coarser filters.  Interesting...and worth remembering for narrow bandwidth
targets.  

The peak echo S/N per run decreased between July 21 and July 23.  Perhaps
that's related to the different phase of the target?  Or were there 
undocumented pointing errors, or some other system problem?

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

                        2000 April 12, 13, & 14

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

REPEAT THE REDUCTION ABOVE USING A 4 K FFT (0.5 Hz RES'N) TO CHECK 
THE BANDWIDTH AND PEAK S/N

Use the PSD file--it already used a 4 K FFT.  There are only 15 FFTs.
I'm not adjusting Tsys.  A lot of the e/m values are very low: < 0.5.
Not so great...

There is a very large spike at the extreme negative frequency.  

Here's the echo:

rows   1021   1022   1023   1024   1025   1026   1027   1028   1029   1030   1031   1032
----------------------------------------------------------------------------------------
   1   0.40  15.88  51.88 222.00 195.05 332.34 104.43 140.01  55.10   9.38   7.93   0.54

rows   1021   1022   1023   1024   1025   1026   1027   1028   1029   1030   1031   1032
----------------------------------------------------------------------------------------
   1   1.55   2.66   3.02  32.27  43.86  56.01  25.20  33.87  10.25   0.80   1.81   1.13

dfreq = 0.244 Hz, so the echo is about 2.2 Hz wide.

dfreq  OC S/N
-----  ------
0.244   332
1       438
1.3     446
1.4     447 <= PEAK  Much smaller than the result I obtained yesterday.
1.5     446
1.6     443
1.7     441
2.0     425

These variations in S/N as a function of smoothing are behaving as I
expect.  

On the other hand, if we reduce the VOLT file with a 4k FFT and smooth that,
here's what I get:

dfreq  OC S/N
-----  ------
0.244   334
1       440
1.3     466
1.4     469 <== PEAK
1.5     469 <==
1.6     467
1.7     
2.0     447

These results are similar to but as much as about 20 sigma larger than
what I got using the PSD file.  

I don't fully understand what's going on with the 0.98-Hz peak S/N 
estimates, but what I'm getting with smoothing the 0.244 Hz results 
seems reasonable since those spectra clearly resolve the echo.  

==> Use the 0.244 Hz spectra to estimate the bandwidths and peak S/N.

W/o baseline removal the peak is about 476 sigma.

- - - - - - - - - - - - - - - - - - - - 

Another question: why are the cross sections obtained after DOY 202 (when we 
used two hops) so much smaller than the cross sections obtained using four 
hops?  If the results continue to be small using the revised rnb software,
then recompute the cross sections using raw hops.  The 0.98 Hz OC S/N
is consistent with what I get when I filter the 0.244 Hz spectra to 1 Hz.
So I'm at a quandary: which S/N estimates do I adopt?  The more conservative
approach would be to adopt the results from the smoothed 0.244 Hz spectra.

That means I need to go back to the first three days and revise the numbers.
For the sake of consistency, reduce the VOLT files and ignore the PSD files.

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

Reduce VOLT files for DOY 199, 201, and 202 to get 0.244 Hz resolution.
Objectives: bandwidths and peak OC S/N estimates.  

I will not fix jsnr1, jsnr2, tsys etc. on these files since I do not
care about the cross sections.

=======
DOY 199
=======

We used 4 kHz sampling, so to get 0.244 Hz res'n use a 16 K FFT.  With 7 runs,
that will take several minutes...

reason:/data/ast5/1999JM8/proc/cw < 24 > dofft -d 5 -p 162 -f 16384 -i VOLT99199.1999JM8 -o 99199.16k.raw.rdf -x PRDX.OUT.s15 
contents of ast_spec control file:
16384,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199.1999JM8
RDFOUT_1=99199.16k.raw.1_1.rdf
RDFOUT_2=99199.16k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199.16k.raw.1.rdf -o 99199.16k.raw.rdf -x PRDX.OUT.s15  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  130
Total SC spectra:  130
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 25 > 

Forge ahead and run this through the rest of the reduction pipeline.

Block everything into one file (leave irun = 1).
There are 130 looks.  

dfreq  OC S/N
-----  ------
0.244   548
0.5     744
1.0     923  
1.1     934
1.2     935
1.3     932
1.4     926
1.5     913
1.6     896
2.0     842

Note: for all the smoothing, I have also been removing baseline with
a first order polynomial afterward, which typically reduces the peak 
S/N by several sigmas.  In retrospect, that wasn't necessary--it was 
more habit than anything else since I always do that when I sum spectra.
You can see that the noise level isn't quite kosher by zooming in on the
spectra.  The noise histograms should reflect this too.

Without baseline removal, the peak immediately above is 936 sigma instead
of 935.  

check the bandwidth using dfreq = 0.244 Hz:

rows   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060   2061   2062   2063
---------------------------------------------------------------------------------------------------------------------------
   1   0.78   2.83   4.56   3.24   7.04  12.31  31.84 321.05 523.55 548.01 413.37 201.92  49.61  11.76   5.90   5.58   1.64

rows   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060   2061   2062   2063
---------------------------------------------------------------------------------------------------------------------------
   1  -0.09   0.30   1.57   1.54   2.24   2.02   3.90  47.29  88.92  78.52  71.29  38.92   7.05   1.65   2.17   0.79   1.26

We're picking up some of the echo's impulse response (and some chi-sq effects) 
so don't use the 2-sigma levels.

Adopt contiguous 5-sigma points: that puts the echo between bins 2051 and 2062,
12 bins total, or the COM + 11 bins.  (0.244 Hz/bin)*(11 bins) = 2.7 Hz.  That's 
MUCH larger than my earlier estimate of 1.5 Hz.  We had a good ephemeris so the
echo shouldn't have been drifting in Doppler (recall that the time base was 9 years).
How did I get such a small estimate before?  I still have the old files in 
/old_cw_files/  I checked the summed 16 K FFT file and using the 5-sigma level I
got a modestly smaller bandwidth, but certainly not 1.5 Hz.  (the difference
can be attributed to the way that sdev was computed--the SNR was too low with
the previous reduction so some of the points near the edges fall below my 
five-sigma limit).  

=======
DOY 201
=======

1 kHz sampling, so use a 4 k FFT.  2 runs.

reason:/data/ast5/1999JM8/proc/cw < 34 > dofft -d 5 -p 162 -f 4096 -i VOLT99201.1999JM8 -o 99201.4k.raw.rdf -x PRDX.OUT.s17
contents of ast_spec control file:
4096,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99201.1999JM8
RDFOUT_1=99201.4k.raw.1_1.rdf
RDFOUT_2=99201.4k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99201.4k.raw.1.rdf -o 99201.4k.raw.rdf -x PRDX.OUT.s17  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  35
Total SC spectra:  35
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 35 > 

Here's the echo (0.244 Hz res'n):

rows    504    505    506    507    508    509    510    511    512    513    514    515    516    517
------------------------------------------------------------------------------------------------------
   1   1.48   3.57   5.75  40.87  88.19 181.57 253.08 221.25 254.49 191.20 126.01  27.13   6.78   1.89

rows    504    505    506    507    508    509    510    511    512    513    514    515    516    517
------------------------------------------------------------------------------------------------------
   1   2.93  -0.27   5.27  11.20  30.58  32.38  41.70  36.70  39.54  27.37  21.28   4.79   1.06   0.11

Echo is in bins 506-516.  11 bins total, or 10 bins + com ==> bandwidth = 2.4 Hz.

Previously I estimated 2.0 Hz, which is also what I get from the 
images (such as they are--less than two runs at MUCH weaker S/N than the CW data).

dfreq  OC S/N
-----  ------
0.244  253
1.0    469
1.2    497
1.4    512
1.5    517
1.6    519
1.7    520 <== 
1.8    519
2.0    513

=======
DOY 202
=======

sampling: 1 kHz ==> 4 k FFT

reason:/data/ast5/1999JM8/proc/cw < 35 > dofft -d 5 -p 162 -f 4096 -i VOLT99202.1999JM8 -o 99202.4k.raw.rdf -x PRDX.OUT.s19 
contents of ast_spec control file:
4096,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99202.1999JM8
RDFOUT_1=99202.4k.raw.1_1.rdf
RDFOUT_2=99202.4k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99202.4k.raw.1.rdf -o 99202.4k.raw.rdf -x PRDX.OUT.s19  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  16
Total SC spectra:  16
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 36 > 

Forge ahead with tkrdfreduc...

only 16 looks.  Lots of chi-sq effects and self noise.

The impulse response is really obvious in this spectrum. 

rows    510    511    512    513    514    515    516    517    518    519    520    521    522   jsnr1   jsnr2
---------------------------------------------------------------------------------------------------------------
   1   4.37   5.27  17.12  80.11 376.13 277.56 270.83 633.58 256.47  41.68   9.47   2.35   1.78   506.0   519.0

rows    510    511    512    513    514    515    516    517    518    519    520    521    522   jsnr1   jsnr2
---------------------------------------------------------------------------------------------------------------
   1   0.20  -0.07   7.70  36.53  46.21  81.17  56.14  54.41  60.34   9.54   0.01   1.03   1.43   506.0   519.0

dfreq  S/N
-----  ----
0.244  634

Echo is between bins 511-520, or 9 bins of echo.
9*(0.24414) = 2.2 Hz.  Previously I got 1.2 Hz.  Yikes!

How does 2.2 Hz compare with the bandwidth in the images?  The images suggest 
a bandwidth of about 1.7 Hz.  Hmm... 0.5 Hz is a significant difference.
Of course, the FFT that I chose is a factor of 2.4 times as coarse as the
one we used with the imaging, so that could account for the difference,
plus the much greater strength of the cw data.  

OK, this doesn't take long, so let's check the bandwidth using an 8 k FFT
(dfreq = 0.122 Hz).  

reason:/data/ast5/1999JM8/proc/cw < 43 > dofft -d 5 -p 162 -f 8192 -i VOLT99202.1999JM8 -o 99202.8k.raw.rdf -x PRDX.OUT.s19
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99202.1999JM8
RDFOUT_1=99202.8k.raw.1_1.rdf
RDFOUT_2=99202.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
 Note: the following IEEE floating-point arithmetic exceptions 
 occurred and were never cleared; see ieee_flags(3M): 
 Inexact;  Invalid Operand; 
 Sun's implementation of IEEE arithmetic is discussed in 
 the Numerical Computation Guide.
/usr/local/bin/jurg2spec -i 99202.8k.raw.1.rdf -o 99202.8k.raw.rdf -x PRDX.OUT.s19  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  7
Total SC spectra:  7
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 44 > 

Hmm...check the spectrum: 

rows   1022   1023   1024   1025   1026   1027   1028   1029   1030   1031   1032   1033   1034   1035   1036   1037   1038   1039   1040
-----------------------------------------------------------------------------------------------------------------------------------------
   1   1.29   4.68  42.03  46.29 107.43 250.74 144.55 175.66 254.98 383.63 314.80 485.03 182.84 257.69  54.88  13.50   5.61   1.84   0.35

rows   1022   1023   1024   1025   1026   1027   1028   1029   1030   1031   1032   1033   1034   1035   1036   1037   1038   1039   1040
-----------------------------------------------------------------------------------------------------------------------------------------
   1   3.15   2.27  12.60  48.70  26.12  30.27  37.28  55.80  53.48  31.65  27.52  57.90  54.50  36.89  23.34   2.13   3.16   0.10   2.32

There aren't any obvious problems.  Lots of chi-sq noise, as expected.

Again adopt the 5-sigma level as a threshold.  There are 15 bins above that level,
or 14 + the COM.  (14)*(0.122 Hz/bin) = 1.7 Hz.  Bingo.  That's consistent with
the bandwidth in the delay-Doppler images.  

So the apparent increase in the bandwidth was a function of frequency resolution.

So... to get more robust estimates of the bandwidths I need to use 0.122 Hz res'n 
in order to put more pixels on the target.  This could have implications for 1999 GU3.

NEED TO USE LONGER FFTs TO GE THE BANDWIDTHS AND OC S/N ESTIMATES.

dfreq  S/N
-----  ---
0.122  485
0.244  574
1.0    814
1.2    831 <==
1.3    831 <== 
1.4    826
1.5    820
1.6    811
2.0    768

=================
DOY 201 REVISITED
=================

Sampling = 1 kHz ==> Use an 8192-point FFT to get dfreq = 0.122 Hz.

There are two runs.

reason:/data/ast5/1999JM8/proc/cw < 6 > dofft -d 5 -p 162 -f 8192 -i VOLT99201.1999JM8 -o 99201.8k.raw.rdf -x PRDX.OUT.s17 
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99201.1999JM8
RDFOUT_1=99201.8k.raw.1_1.rdf
RDFOUT_2=99201.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99201.8k.raw.1.rdf -o 99201.8k.raw.rdf -x PRDX.OUT.s17  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  17
Total SC spectra:  17
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 7 >

At this res'n there are only 17 looks.

Here's the echo:

ows   1012   1013   1014   1015   1016   1017   1018   1019   1020   1021   1022   1023   1024   1025   1026   1027   1028   1029
----------------------------------------------------------------------------------------------------------------------------------
   1   3.52  31.25  60.50  69.46  58.57 142.28 128.82 165.31 133.45 174.50 134.45 194.70 147.04 157.94 140.63 104.17  64.64   9.31

rows   1012   1013   1014   1015   1016   1017   1018   1019   1020   1021   1022   1023   1024   1025   1026   1027   1028   1029
----------------------------------------------------------------------------------------------------------------------------------
   1   2.37   4.80   8.68  20.85  29.48  26.28  37.85  17.67  37.71  34.84  21.52  28.46  38.36  21.39  23.29  10.99   6.98   1.95

There are 17 points above the 5-sigma level, so the bandwidth is:
16*(0.122 Hz/bin) = 1.953 Hz = 2.0 Hz.  That matches the bandwidth 
in the delay-Doppler image.  

dfreq  OC S/N
-----  ------
0.122  195
0.244  250
1.0    446
1.5    499
1.6    501
1.7    503
1.8    504 <== 
1.9    502

=================
DOY 199 REVISITED
=================

Sampling = 4 kHz, so we need a 32 k FFT to get 0.122 Hz resolution.  
There are seven runs, so this will be slow.  The raw file will be quite large.

reason:/data/ast5/1999JM8/proc/cw < 13 > dofft -d 5 -p 162 -f 32768 -i VOLT99199.1999JM8 -o 99199.32k.raw.rdf -x PRDX.OUT.s15 
contents of ast_spec control file:
32768,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199.1999JM8
RDFOUT_1=99199.32k.raw.1_1.rdf
RDFOUT_2=99199.32k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
 Note: the following IEEE floating-point arithmetic exceptions 
 occurred and were never cleared; see ieee_flags(3M): 
 Inexact;  Invalid Operand; 
 Sun's implementation of IEEE arithmetic is discussed in 
 the Numerical Computation Guide.
/usr/local/bin/jurg2spec -i 99199.32k.raw.1.rdf -o 99199.32k.raw.rdf -x PRDX.OUT.s15  -p 162 -d 5 
Bus Error
reason:/data/ast5/1999JM8/proc/cw < 14 > 

Great.  Now what...?  There's still plenty of space on /data/ast5, so that shouldn't
be the problem.  Maybe it's a RAM problem?  

OK, use file 99199B: it has only 3 runs with 1 kHz sampling, so we can use an 8 k FFT.

First delete all the 32 k FFT files...

reason:/data/ast5/1999JM8/proc/cw < 23 > dofft -d 5 -p 162 -f 8192 -i VOLT99199B-8k.1999JM8 -o 99199B.8k.raw.rdf -x PRDX.OUT.s15
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199B-8k.1999JM8
RDFOUT_1=99199B.8k.raw.1_1.rdf
RDFOUT_2=99199B.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199B.8k.raw.1.rdf -o 99199B.8k.raw.rdf -x PRDX.OUT.s15  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  4
Total OC spectra:  26
Total SC spectra:  26
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 24 > 

rows   1032   1033   1034   1035   1036   1037   1038   1039   1040   1041   1042   1043   1044   1045   1046
-------------------------------------------------------------------------------------------------------------
   1   2.92  27.37 124.15  95.35 148.20 118.89 123.45 110.43  77.49  98.11  58.22  62.83  31.98  18.32   2.77

rows   1032   1033   1034   1035   1036   1037   1038   1039   1040   1041   1042   1043   1044   1045   1046
-------------------------------------------------------------------------------------------------------------
   1  -0.82   1.16  16.40   7.69  19.80  18.11  11.05  19.89  30.78  13.00  16.38  10.46   8.79   0.22   2.13

There are 13 Doppler bins above the 5-sigma level, so the bandwidth is
12(0.122 Hz/bin) = 1.46 Hz.  That's only about 1/2 of what I got using
coarser res'n spectra from the first file on this date.  However, this
estimate is the same as the one I have from last fall using the same
data.  

For the S/N estimate, ideally I'd prefer to have it for file 99199, not
file 99199B.  The S/N per run will be somewhat different because the
elevation (and thus Tsys and the gain) were different during acquisition
of file 99199B: the elevation was much lower.  However, in the interest of
not wasting any more time, use the estimate from file 99199 with a 16 k FFT
(dfreq = 0.244 Hz).  The S/N from that file should be very similar to what
I'd get using 99199B and adjusted for the different number of runs.

Result: 935 sigma

=======
DOY 204
=======

We did one CW run with 1 kHz sampling, so use an 8 k FFT:

Note: we used two hops.

reason:/data/ast5/1999JM8/proc/cw < 32 > dofft -d 5 -p 162 -f 8192 -i VOLT99204.1999JM8 -o 99204.8k.raw.rdf -x PRDX.OUT.s21
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99204.1999JM8
RDFOUT_1=99204.8k.raw.1_1.rdf
RDFOUT_2=99204.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99204.8k.raw.1.rdf -o 99204.8k.raw.rdf -x PRDX.OUT.s21  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  7
Total SC spectra:  7
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 33 > 

There are only 7 looks at 0.122 Hz resolution.

There's a very large spurious spike at the extreme negative edge
of the spectrum.  It's about 4 times stronger than the echo.

Obviously chisq noise is very strong.  

rows   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059
--------------------------------------------------------------------------------------------------------------------
   1   2.98  23.06  68.79 242.72 143.45 236.40 104.19 226.97 149.48  54.86 449.94 109.65  69.58 170.01   6.17   3.94

rows   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059
--------------------------------------------------------------------------------------------------------------------
   1   1.06  -0.13   9.07  35.29  23.59  30.63  25.69  44.65  31.50  23.93   8.90  32.11  11.46  12.73  10.81   0.39

Adopt 5-sigma as a threshold.  There are 14 Doppler bins, so the echo bandwidth
is: 13*(0.122 Hz/bin) = 1.59 Hz.  The bandwidth from the delay-Doppler image is
1.5 Hz, so the results are consistent.  

dfreq OC S/N
----- ------
0.122  450
1.0    530
1.4    579
1.5    581 <==
1.6    581 <==

=======
DOY 205
=======

Sampling = 1 kHz, runs = 2, hops = 2

Go for the bandwidth and S/N first and then for the cross sections & ratio.

Use an 8 k FFT.  

reason:/data/ast5/1999JM8/proc/cw < 39 > dofft -d 5 -p 162 -f 8192 -i VOLT99205.1999JM8 -o 99205.8k.raw.rdf -x PRDX.OUT.s21 
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99205.1999JM8
RDFOUT_1=99205.8k.raw.1_1.rdf
RDFOUT_2=99205.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99205.8k.raw.1.rdf -o 99205.8k.raw.rdf -x PRDX.OUT.s21  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  12
Total SC spectra:  12
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 40 > 

There are 12 looks.

At the 0.122 Hz res'n the echo strength is about 500 sigma.  There is a lot of
chi-square noise.  There's also another strong spike at about -209 Hz that may
be chi-sq noise, but it's very strong: about 80 sigma.  Of course, sigmas don't
have much meaning with only 12 FFTs...  The feature appears to be only 1 bin
wide so my guess is that it's just chi-sq noise.  I used an 8 k FFT so there should
be several rather strong noise spikes.

rows   2042   2043   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060   2061   2062   2063
--------------------------------------------------------------------------------------------------------------------------------------------------------------
   1   1.76   5.77  15.26  34.10  78.27 104.50 185.33 221.35 498.12 417.50 414.06 383.51 429.98 323.79 240.75  97.00 468.97  53.70  17.60  16.75   8.42   3.56

rows   2042   2043   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060   2061   2062   2063
--------------------------------------------------------------------------------------------------------------------------------------------------------------
   1   1.18   0.73   0.52  12.22  35.93  26.86  46.28  60.71 153.71  88.35  69.24 152.06 132.82  35.90  89.27  62.71   1.83   5.95   2.35  -0.76  -1.02  16.11

Adopt 5-sigma as a threshold, even though that could widen the bandwidth
due to chi-sq noise.

There are 20 bins, so the bandwidth = (19)*(0.122 Hz/bin) = 2.32 Hz

I count 22 Doppler bins in the image, so the bandwidth is 22(0.075) = 1.65 Hz.
Why such a large difference?  Chi-square noise?  The image has much less 
chi-sq noise because we did 49 runs.  The bandwidths would be consistent if
we ignored the two most negative and three most positive points.  Those adjacent
points are probably part of the impulse response--there aren't many
noise points above 10 sigmas elsewhere in the spectrum.  

dfreq OC S/N
----- ------
0.122  498
1.0   1068
1.4   1124
1.5   1125 <==
1.6   1122
2.0   1087

Estimate the cross sections
===========================

The raw rdf file with 1.95 Hz res'n already exists: 99205.nocal.corrected.rdf

There are 236 looks.

Currently Tsys ch1 = 17.1, ch2 = 17.9  Those are valid temps for elevation = 40 deg.
The tx/rcv log didn't record temps on this day, but they aren't likely to be very
different because the elevation increased by less than 1.5 degrees.  ==> Adopt
these Tsys values.  

e/m values in both channels for the first 74 hops are quite low: <= 0.2.  ??
Something is wrong with those hops.  Randy's notes indicate that we were using
new GSSR software that had some problem, so they switched to the old software.
Perhaps that's the cause of the bad spectra.  ==> Delete them.  

e/m values still aren't uniformly great but the systematic bad values are gone.

There are 162 looks.

change jsnr1,2 = 123,135

rows   123   124   125   126   127   128   129   130   131   132   133   134   135   jsnr1   jsnr2
--------------------------------------------------------------------------------------------------
   1  0.77  3.68  2.64  2.48 10.70 18.93700.66109.87 11.88  3.00  2.18  3.10  0.95   123.0   135.0

rows   123   124   125   126   127   128   129   130   131   132   133   134   135   jsnr1   jsnr2
--------------------------------------------------------------------------------------------------
   1  1.34 -1.27  0.03  0.33  0.68  4.67 96.39 18.98  5.20  0.74  0.14 -0.31 -1.18   123.0   135.0

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99205.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   1-oc  16:59:05  00:00:00  17:01:53   0.0   3.27e-03   2.85e+00  4.0e-03  2.9
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99205.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/24   1-sc  16:59:05  00:00:00  17:01:53   0.0   3.42e-03   4.31e-01  4.4e-03  3.2 0.151333 0.152884 0.149783

OCxsec = 2.85 km^2
SCxsec = 0.43 km^2
SC/OC  = 0.15

Check the noise statistics: they look fine.

================
DOY 208: July 27
================

2 runs, 2 hops, 1 kHz sampling ==> use an 8 k FFT.
reason:/data/ast5/1999JM8/proc/cw < 46 > dofft -d 5 -p 162 -f 8192 -i VOLT99208.1999JM8 -o 99208.8k.raw.rdf -x PRDX.OUT.s21
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99208.1999JM8
RDFOUT_1=99208.8k.raw.1_1.rdf
RDFOUT_2=99208.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99208.8k.raw.1.rdf -o 99208.8k.raw.rdf -x PRDX.OUT.s21  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  10
Total SC spectra:  10
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 47 > 

We got 9 looks.  Expect lots of chi-sq noise again.

rows   2042   2043   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060   2061   2062   2063   2064   2065
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1    1.5    8.0   51.7  119.1   46.9   78.9  195.1  233.2  107.6  120.5  104.8   98.0  204.9  135.7  210.9   83.6   36.1  157.9   72.6   93.4   48.2   18.5   16.8    0.8

rows   2042   2043   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060   2061   2062   2063   2064   2065
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1    3.9   -1.0    6.1   14.2   16.1   21.5   39.0   41.6   24.3   37.1   34.1   46.5   32.2   16.6   18.8   28.6   20.3   13.7   18.1    7.9    4.0    1.4   -0.3   -0.1

The echo is clearly wider than on previous days.  If we use 5 sigma as the threshold,
then the bandwidth is (21 bins)(0.122 Hz/bin) = 2.56 Hz.  How does that compare with
the bandwidth from the images?  67-18 = 49 bins, so 48(0.05 Hz/bin) = 2.4 Hz.
We did 30 runs with the 1/4 us x 0.05 Hz setup and the echo edges aren't well
defined, so these bandwidth differences are not a big deal.  

dfreq OC S/N
----- ------
0.122  233
1.0    416
2.0    516
2.2    519
2.3    520
2.4    519
2.6    515

Note that the S/N is down by more than a factor of two relative to the
previous day.  The delay-doppler image is weak too.  Possible reasons
are that the pointing was bad, although we don't have any way to check for
that a posteriori.  The image suggests that we were seeing a pointed end
and that there wasn't as much projected area as on the previous day.

Estimate the cross sections
---------------------------
file = 99208.512.raw.corrrected.rdf

There are 216 looks.  
Tsys ch1 = 18.2 K
     ch2 = 19.5 K

The tx/rcv log indicates that correct values are:
     ch1 = 18.4 K
     ch2 = 19.6 K

Close enough.  The values above were obtained at a slightly different 
elevation immediately prior to the commencement of the observations.

the other tags look fine.

Change jsnr1 and 2:

rows    122    123    124    125    126    127    128    129    130    131    132    133    134    135   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1   0.21   3.37   2.83   0.33   2.33   6.98  19.08 382.51 131.39   9.09   2.18   2.64   4.46  -0.77   122.0   135.0

rows    122    123    124    125    126    127    128    129    130    131    132    133    134    135   jsnr1   jsnr2
----------------------------------------------------------------------------------------------------------------------
   1   0.40   1.20   1.16  -0.62   0.01   1.32   4.77  67.72  18.50   2.32  -1.02  -1.56   0.17  -1.25   122.0   135.0

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99208.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-oc  01:31:16  00:00:00  01:34:22   0.0   1.90e-03   1.08e+00  2.7e-03  3.8
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99208.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/27   1-sc  01:31:16  00:00:00  01:34:22   0.0   2.04e-03   1.90e-01  2.7e-03  3.4 0.176074 0.178611 0.173539

OCxsec = 1.08 km^2
SCxsec = 0.19 km^2
SC/OC  = 0.18

Wow!  The cross section is WAY down relative to those on previous days.  
That's in keeping with the generally weak image and lower S/N from above.

Check the noise statistics: OC histogram looks fine.  SC has a slight excess of points
near 0 sigma.  I used different numbers of histogram bins but that didn't really
change much.  

================
DOY 209: July 28
================

Sampling = 1 kHz, hops = 2, runs = 1, osod = 23 => use 8 k FFT

reason:/data/ast5/1999JM8/proc/cw < 50 > dofft -d 5 -p 162 -f 8192 -i VOLT99209.1999JM8 -o 99209.8k.raw.rdf -x PRDX.OUT.s23
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99209.1999JM8
RDFOUT_1=99209.8k.raw.1_1.rdf
RDFOUT_2=99209.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99209.8k.raw.1.rdf -o 99209.8k.raw.rdf -x PRDX.OUT.s23  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  4
Total SC spectra:  4
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 51 > 

Only 4 looks!  Yikes!

The echo strength is WAY up relative to the previous day.  Obviously there's 
considerable self noise at echo-containing frequencies too.  These echoes were
obtained near the closest approach.  

There are 25 contiguous bins exceeding 5-sigma, so with that threshold the 
bandwidth is (24)(0.122) = 2.93 Hz.  However, chi-sq noise and the impulse 
response could easily have broadened the echo, so let's compare it with 
the delay-Doppler image: 62-7 = 55 bins => (54)*(0.05 Hz/bin) = 2.7 Hz.
Note that the images also have finer Doppler resolution than the CW spectra
by slightly more than a factor of two.  

What will happen when we smooth this spectrum?  ==> I tried doubling dfreq
from 0.122 Hz -> 2.0 Hz and found that the echo smooths into something
reasonable when dfreq = 0.5 Hz.  Mike Nolan and I briefly discussed this
last year during the JM8 experiment when he ran a very long FFT on one of the
JM8 cw spectra.  The FFT was so long that we had only one look, so the echo 
was riddled with self noise.  Mike claimed you could smooth it and recover
a "normal" looking echo and he was right.  I hadn't experimented with such 
extreme FFTs before so I wasn't sure.  

dfreq  OC S/N
-----  ------
0.122  5353

1.0    5340

1.5    5569

2.0    5686
2.1    5705
2.2    5701
2.4    5656
2.5    5607

This is about 10 times stronger than the returns from the previous
day.  It's hard to believe that there was that much change in the 
object's orientation combined with an odd shape, so perhas there were
pointing problems on July 27.  

Estimate the cross sections
---------------------------
There are only 80 hops: I did only one run.  I should have done at least
one more to be safe.  

file: 99209.nocal.512.new.rdf

Tsys:
ch1 = 15.6, ch2 = 16.7

Those are the values we measured immediately prior to transmitting so
they're fine.  The actual values for the one run were not recorded:
My notes indicate that the one cw run was accidentally truncated.  

e/m values are highly variable with the usual pattern.
The hops are also highly variable but they look OK.  

change jsnr1,2 = 124, 134

rows    122    123    124    125    126    127    128    129    130    131    132    133    134    135
------------------------------------------------------------------------------------------------------
   1    2.6    3.1    2.1    4.8   10.9   19.8  134.8 1050.5  204.9   21.3    8.4    5.1    1.8    1.7

rows    122    123    124    125    126    127    128    129    130    131    132    133    134    135
------------------------------------------------------------------------------------------------------
   1   -0.4    0.5    0.4    2.2   -0.4    3.5   20.8  154.0   42.5    3.3    5.7    0.1    0.1   -0.3

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99209.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-oc  17:14:29  00:00:00  17:15:14   0.0   2.06e-03   3.02e+00  2.8e-03  3.6
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99209.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/28   1-sc  17:14:29  00:00:00  17:15:14   0.0   2.22e-03   5.15e-01  3.2e-03  4.1 0.170468 0.171537 0.169399

OCxsec = 3.02 km^2
SCxsec = 0.52 km^2
SC/OC  = 0.17

So what happened on the day before?  It's not obvious whether everything was 
weaker on July 27 because the pointing was bad (which is possible), because of
the shape of the object and its shape (perhaps more likely), some other undocumented
system problem, or some combination of these factors.  We may should get some constraints
from the shape modeling.  

================
DOY 212: JULY 31
================

Sampling = 1 kHz, hops = 2, osod = 23, runs = 2.

reason:/data/ast5/1999JM8/proc/cw < 54 > dofft -d 5 -p 162 -f 8192 -i VOLT99212.1999JM8 -o 99212.8k.raw.rdf -x PRDX.OUT.s23 
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99212.1999JM8
RDFOUT_1=99212.8k.raw.1_1.rdf
RDFOUT_2=99212.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
 Note: the following IEEE floating-point arithmetic exceptions 
 occurred and were never cleared; see ieee_flags(3M): 
 Inexact;  Invalid Operand; 
 Sun's implementation of IEEE arithmetic is discussed in 
 the Numerical Computation Guide.
/usr/local/bin/jurg2spec -i 99212.8k.raw.1.rdf -o 99212.8k.raw.rdf -x PRDX.OUT.s23  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  8
Total SC spectra:  8
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 55 > 

rows   2031   2032   2033   2034   2035   2036   2037   2038   2039   2040   2041   2042   2043   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1    2.4   50.2   70.9  164.9  226.5  149.9  242.8  241.0  200.0   99.0  389.8  237.2  585.9  157.4  172.7  427.7  425.1  174.8  240.9  349.9  760.3  377.1  198.6  484.2  124.8   92.7   83.5  131.8   17.2    3.6

rows   2031   2032   2033   2034   2035   2036   2037   2038   2039   2040   2041   2042   2043   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1    6.7   15.1   27.6   33.3   80.4   20.0   14.9  183.7   80.9   47.4   18.7   33.6  236.4   32.0   22.8   27.9   51.7   26.5   40.1   25.0  106.3   50.1   48.7  101.3   58.1   34.4   11.3    6.9    6.9    0.3

There are 28 bins, so the bandwidth = (27)(0.122 Hz/bin) = 3.30 Hz
Compare that with the image: ~65*(0.05 Hz/bin) = 3.25 Hz.  Good agreement.

dfreq OC S/N
----- ------
0.122  760
1.0   1085
1.5   1196
2.0   1321
2.2   1348
2.5   1376
2.8   1396
3.0   1398 <==
3.2   1393

Estimate the cross sections
---------------------------
There are 180 looks.  

The raw file already exists: 99212.nocal.512.rdf

Tsys ch1 = 15.3, ch2 = 16.4

Should be: 15.2, 16.2  The difference is less than 2% so leave 
Tsys values as the are.

e/m values are about normal, perhaps a shade closer to unity in some cases.

rows    122    123    124    125    126    127    128    129    130    131    132    133    134    135
------------------------------------------------------------------------------------------------------
   1    0.9    2.8    3.1    4.7   10.8   25.4  375.2  748.7   90.9   15.3    6.8    3.2    2.3    2.0

rows    122    123    124    125    126    127    128    129    130    131    132    133    134    135
------------------------------------------------------------------------------------------------------
   1    1.7   -0.7    0.8    0.4    3.0    4.9   77.5  151.2   19.6    2.7    0.3    4.0   -0.4    2.0

change jsnr1,2 = 122, 135.

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99212.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/31   1-oc  17:01:12  00:00:00  17:04:03   0.0   1.50e-03   1.94e+00  2.3e-03  4.6
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99212.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/31   1-sc  17:01:12  00:00:00  17:04:03   0.0   1.61e-03   4.29e-01  2.5e-03  4.7 0.220968 0.222285 0.219651

OCxsec = 1.94 km^2
SCxsec = 0.43 km^2
SC/OC  = 0.22

Noise statistics look OK, although there's another slight excess of points 
near zero standard deviations in the SC spectrum.  

=================
DOY 213: AUGUST 1
=================

Sampling = 1 kHz, hops = 2, runs = 2, osod = 23

reason:/data/ast5/1999JM8/proc/cw < 58 > dofft -d 5 -p 162 -f 8192 -i VOLT99213.1999JM8 -o 99213.8k.raw.rdf -x PRDX.OUT.s23
contents of ast_spec control file:
8192,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99213.1999JM8
RDFOUT_1=99213.8k.raw.1_1.rdf
RDFOUT_2=99213.8k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99213.8k.raw.1.rdf -o 99213.8k.raw.rdf -x PRDX.OUT.s23  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  10
Total SC spectra:  10
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 59 > 

There are 10 looks.

Here's the OC component of the echo:

rows   2031   2032   2033   2034   2035   2036   2037   2038   2039   2040   2041   2042   2043   2044   2045   2046   2047   2048   2049   2050   2051   2052   2053   2054   2055   2056   2057   2058   2059   2060   2061
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1    3.2   10.0   68.5   55.3   77.8   69.4  121.8  145.1   33.5  141.1  167.1  149.1  281.7  167.5  110.9  347.6  111.8  228.2  219.1  224.3  170.0  365.2  410.9   85.1  121.5   97.3  211.0  108.7   22.2    8.4    1.9

There are 29 bins exceeding 5 standard deviations.  Bandwidth = 28*(0.122 Hz/bin) = 3.42 Hz.
Compare with the bandwidth of the echo: 84-22 = 62 bins  (61 bins)(0.05 Hz/bin) = 3.05 Hz.
That's a pretty big difference, but perhaps it results because the images have more than
twice the resolution of the CW spectra.  I could go up to a 16 k FFT to check...

reason:/data/ast5/1999JM8/proc/cw < 66 > dofft -d 5 -p 162 -f 16384 -i VOLT99213.1999JM8 -o 99213.16k.raw.rdf -x PRDX.OUT.s23
contents of ast_spec control file:
16384,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99213.1999JM8
RDFOUT_1=99213.16k.raw.1_1.rdf
RDFOUT_2=99213.16k.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
 Note: the following IEEE floating-point arithmetic exceptions 
 occurred and were never cleared; see ieee_flags(3M): 
 Inexact;  Invalid Operand; 
 Sun's implementation of IEEE arithmetic is discussed in 
 the Numerical Computation Guide.
/usr/local/bin/jurg2spec -i 99213.16k.raw.1.rdf -o 99213.16k.raw.rdf -x PRDX.OUT.s23  -p 162 -d 5 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  4
Total SC spectra:  4
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 67 > 

Only 4 hops!  There are several noise spikes exceeding 50 sigmas.
5 sigma is not an appropriate threshold for so few looks.  Self noise is
also horrible so forget it.  The image is more robust since it has almost
100 runs and probably about that number of looks.  

Return to the 0.122 Hz spectra and get S/N estimates

dfreq OC S/N
----- ------
0.122  411
2.0    849
2.5    877
2.7    880
2.8    881
3.0    880
3.2    
3.5    867

Estimate the cross sections
===========================

The raw file with 1.95 Hz res'n already exists: 99213.nocal.512.rdf

I was not at Goldstone for this track so the electronic log is very sparse.

There are 192 FFTs.  

The tx/rcv log indicates that Tsys should be: ch1 = 16.95, ch2 = 18.0
Check Tsys: ch1 = 15.1, ch2 = 16.1.  These temps are about 2 K too high.
I changed them to the values above. 

The other tags look fine. Of course, irun = 1, but I'm grouping into a file
so that's fine.  

run the raw file the rest of the way through /dev1/wart/bin/tkrdfreduc...

e/m values aren't so great... with the usual discrepancy between OC and SC.

rows    120    121    122    123    124    125    126    127    128    129    130    131    132    133    134    135   jsnr1   jsnr2
------------------------------------------------------------------------------------------------------------------------------------
   1   1.56  -0.12   3.45   4.15   5.39   5.61  13.31  27.07 218.73 885.29 125.17  31.11  13.60   6.32   3.58   3.09   122.0   135.0

rows    120    121    122    123    124    125    126    127    128    129    130    131    132    133    134    135   jsnr1   jsnr2
------------------------------------------------------------------------------------------------------------------------------------
   1   0.68   0.46  -0.75  -0.09   0.85   1.15   4.39   6.99  53.62 190.63  26.24   1.47   1.73   3.63   0.87   3.35   122.0   135.0

jsnr1 and 2 are set generously wide.  They include some of the impulse
response but it's low enough to be down in the standard errors.

Noise histograms look good for both channels.

Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99213.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/08/01   1-oc  12:03:22  00:00:00  12:06:16   0.0   1.35e-03   1.81e+00  2.0e-03  4.2
Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99213.512.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/08/01   1-sc  12:03:22  00:00:00  12:06:16   0.0   1.43e-03   4.20e-01  2.1e-03  4.2 0.23204 0.233227 0.230853

OCxsec = 1.81 km^2  <== Before I got 1.6 km^2
SCxsec = 0.42 km^2
SC/OC  = 0.23

Why is the cross section so low?  On July 31 the apparent rotation phase is very similar 
to the one on July 24 when the cross sections and ratio were:

OCxsec = 2.85 km^2
SCxsec = 0.43 km^2
SC/OC  = 0.15

What's going on?  The images on July 24 and August 1 look very similar.  The 
main difference is that there appears to be more echo power from inside the large
concavity in the July 24 image.  There's also a modest rotation in Doppler between
the two images.  

Is this another example of Goldstone's unreliability?

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

Between July 18 and August 1 we got cross sections and ratios on 9
days.  The cross sections varied between 1.1 km^2 and 3.5 km^2 and
SC/OC varied between 0.15 and 0.23.  The means are 2.5 km^2 and 0.19.

Some of the variation in the cross sections is probably real: the asteroid
has a peculiar shape that was oriented differently from day to day, but
the distinct difference in the cross sections on July 24 and 31 makes me
suspicious that there are substantial undocumented systematic errors, 
perhaps in the pointing. 

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

2001 April 19 & 20

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

I have resumed work on JM8.  We decided to postpone the shape modeling because Scott's
efforts to constrain the spin state weren't converging.  He turned everything over to
me.  So we'll publish a paper describing as much about the object as possible without
the shape.  

- - - - - - - - - - - - - - - - -

I have prepared collages of OC, SC, and SC/OC images.  The OC and SC collages use
the same Doppler and range extents in each frame and I set the number of horizontal
pixels so the Doppler axes in the Goldstone and Arecibo images can be directly
compared.  

I also created a 3-panel sequence of the doy 220 (Aug 8) Goldstone images
that show very subtle rotation.  Steve suggested animating some gifs to show the rotation.
The sequence on that day spans more than 7 hours and it clearly shows that the rotation
is very slow.  It's so slow that sky motion could have contributed significantly to the 
apparent rotation.  

- - - - - - - - - - - - - - - - - 

Spin state
==========

Images on July 24 and Aug. 1 show nearly the same part of the asteroid but the bandwidths
are distinctly different: on July 24 the bandwidth is about 1.7 Hz but on Aug. 1 it's about
3.0 Hz.  Clearly the apparent subradar latitude has moved closer to the apparent equator.
The Aug. 8 image is also similar to the other two (but with some rotation).  Steve points
out that we can use the very similar appearance of the images to test hypotheses about the
spin state.  We strongly suspect NPA rotation; in the absence of shape modeling results, 
we're going to search for contradictions to the PA rotation hypothesis.  

Ideas
-----
1. Assume PA rotation and do a 3-D spin state grid search over lat, long, period.  See if 
   there are any viable candidates using the images from Jul 24, Aug 1, and Aug 8.  

2. Plot RA and DEC on a globe to psych out the sky motion better.  Try to get a transluscent 
   globe that can be split into two hemispheres.  

3. Prove that the asteroid is in fact rotating.  That's easy: we see it directly in the images,
   despite the considerable sky motion.  Get a cheap globe and put small stickers on it to show
   the asteroid's positions.

4. Try to visualize JM8's motion across the sky.  

5. Create new image collages that interweave the Goldstone and Arecibo images; leave blanks
   at the locations of dates when we didn't observe.  

   Jul 20
   Jul 21
   Jul 22 blank
   Jul 23
   Jul 24 
   Jul 25 blank
   Jul 26 blank
   Jul 27 
   Jul 28
   Jul 29 blank
   Jul 30 blank
   Jul 31
   Aug  1 
   Aug  2
   Aug  3
   Aug  4
   Aug  5
   Aug  6
   Aug  7
   Aug  8
   Aug  9
   blank 
   blank
   blank

21 days total==> make three 8-panel images

6. Use one of the PRDX files to compute the angular rate vs. time.  Difference
   pairs of lines.  

7. Use bandwidths and visible range extents to estimate period, check results for consistency.
   Expect significant differences.  

8. Check for rotation during the Arecibo tracks: look at groups of images at the beginning
   and end of each day.  Use the Aug. 5 track: it's the longest (1.37 h) and it appears to be
   one of the days that showed the most rotation relative to surrounding days.   We estimate that
   we're seeing about 50 deg of rotation between Aug 5 and 6.  The sky motion was about 4 deg, so 
   apparent rotation is slightly more than 10x larger than sky motion.  If we adopt 50 deg of 
   rotation as our estimate, then JM8 rotated about 2 deg/h if the rotation is constant.  Over 
   1.37 h, we might see 2.7 deg of rotation.  That's not much but it's potentially detectable
   with such fine resolution and high SNR.   I grouped the first and last five runs on Aug. 5.
   There is a modest amount of rotation that appears consistent with 2-3 degrees predicted
   by the simple calculation above.   The SNR is high enough that to check the first and last
   runs without any summing. ==> The Doppler frequencies of features at the positive and negative
   edges differ by several bins.  The leading edge of the prominent feature at positive freqs 
   changed by about 9 gates or about 135 meters.  We also checked by printing reverse grayscale
   figures, making viewgraphs, and overlaying them.  The rotation is evident at the locations 
   mentioned above.  One could go even farther by giving the viewgraphs different colors, but
   that's not necessary.  Set up the script next.  

contradiction between daily apparent rotation on Aug 4-5-6 and the very small rotation
seen during 7.5 h on Aug. 8.  

Pole Search
-----------
Still want to test PA rotation using radpole for a suite of rotation periods and pole directions.
Search over the whole sky and search a range of rotation periods at small intervales.  The
bandwidths to test are from Jul 24 and Aug 1 and 8.  Use relatively coarse resolution in 
lat & long--say, no more more than 5 degrees.  Start with periods of roughly 5-9 days.

This will produce figures suitable for viewing with Spyglass Transform, giving chisq as a function
of long and lat.  

This type of search could be very time-consuming.  Even viewing the results will be time 
consuming.  Perhaps write another Perl script to search the output files to locate the 
minima?  That would make a lot more sense than inspecting each figure.  View a few figures
to get a sense of the chisq structure/number of minima and then automate it.

I used Horizons to compute an ephemeris for Goldstone from 1999 July 16-August 12 at hourly
intervals.  I input bandwidths and error estimates at three epochs corresponding to the midpoints
of the Goldstone observations on July 24, Aug. 1, and August. 8.  The mean visible range extent of
all the images is 3.3 km, but I suspect that the true range extents are somewhat less than twice
the visible range extents on at least some of the days, so I adopted Deff = 5 km as an educated
guess.  

Each pole search at 5 deg resolution will take roughly a few minutes.  Perhaps we should 
reduce the resolution to 10 degrees...  done.  Write a script to scan through a range of rotation
periods.  

reason:/data/ast5/1999JM8/analysis/pole_search < 94 > polesrch jm8.ephem jm8.epochs jm8.search jm8.residuals jm8.chisq

The first chisq plot was weird--chisq varied from ~0.1 to about 3.6.  ??  Recall Keith's instructions
on the internal software pages.

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

2001 April 22 & 23

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

I found some bugs in Keith's polesrch documentation: It turns out that his polesrch Perl script
ignores long = 0 deg if the 0 is placed first in the search file, so place 0 after 355 instead:

# 1999JM8.search
#
# Pole search space for 1999 JM8, diameter = 5000 meters.
# 
# 2001 April 22
#
#-----------------------------------------------------------------------------------------
# 5-degree all-sky search:

betas: 0  5  10  15  20  25  30  35  40  45  50  55  60  65  70  75  80  85  90 
betas:   -5 -10 -15 -20 -25 -30 -35 -40 -45 -50 -55 -60 -65 -70 -75 -80 -85 -90 

lambdas:    5  10  15  20  25  30  35  40  45  50  55  60  65  70  75  80  85  90  95  100 
lambdas:  105 110 115 120 125 130 135 140 145 150 155 160 165 170 175 180 185 190 195  200 
lambdas:  205 210 215 220 225 230 235 240 245 250 255 260 265 270 275 280 285 290 295  300 
lambdas:  305 310 315 320 325 330 335 340 345 350 355   0

diameters:   5000

Oddly, beta = 0 works fine.  This appears to be Perl parsing issue.  I could delve into Keith's 
script but it's probably not worth my time (yet).  We should change Keith's online documentation,
though.

Furthermore, when plotting with Transform don't use linear interpolation to fill the array--
leave the array as it is.  However, it's probably necessary to set the dimensions of the array
(i.e. the "target matrix") manually because Spyglass' defaults are usually wrong.  Otherwise
Transform is likely to ignore some of the columns. 

- - - - - - - - - - - - - - - - - - - - 

I ran some test cases over the weekend to figure out 
1) how to plot with Transform (see above) and
2) how to tackle this problem in general.  

It's my intent to scan a range of sidereal rotation periods and to search the entire sky at 5 or 10 deg 
resolution.  The question is: how to interpret the results?  polesrch outputs 2 text files: one with 
residuals to each estimate and the other with chisq values.  It's possible to get small chisq (< 1.0) 
if two bandwidth estimates are fit well even if the other is fit only at the 2-3 sigma level, so be
careful.  My script is going to parse the chisq file to identify the best fits to all three bandwidths 
and then parse the other file to output the individual residuals.  I'll write another script to sweep
through a range of rotation periods automatically.  Be careful not to fill the partition; the residual
files can be large. (~0.5 meg).  

I also double checked the bandwidth estimates and errors that I have assigned and I modified them 
slightly.  I tightened the errors on doy 220 and I increased the bandwidth estimate on doy 213 by
using the Arecibo images to estimate the bandwidth instead of the Goldstone images.  That increased
the bandwidth by about 0.1 Hz. 

In the script, after identifying the best candidates, use the estimated errors to compute the 
magnitude of the residuals in standard deviations for each measurement.  

To speed things up, adopt a resolution of 10 deg in lambda and beta.

Another idea: use radpole/radgeo to predict longitudes at different epochs given
bandwidth measurements...but that requires a pole.  My thinking is to see if we can assume PA rotation
and see the same side of JM8 on July 24, Aug 1, and Aug 8.  

With only 3 bandwidth measurements, the one-sigma level of statistical significance is
rather large (as a percentage over the minimum)...

- - - - - - - - - - 

I wrote a Perl script to run through a range of periods:

jm8.polesearch.pl  

Presently I'm using 10 deg resolution.  Each run takes roughly 100 seconds (based on only 2 runs, though).
If this is representative, then searching periods between 5.0 - 9.0 days at 0.1 day intervals will take
just over 1 hour.  

To speed things up, run this on rhyme, freeing up reason for other jobs (Steve and I tend to use reason
a lot more than rhyme).  

I wrote another Perl script to parse the residuals and chisq files, identify poles with chisq < some
threshold, and output the results to a new file.  

jm8.pole.pl

I set jm8.polesearch.pl running overnight on rhyme using 5 degree resolution and a period increment
of 0.05 days (1.2 hours).  

A significant concern: how reliable is the bandwidth on August 8?  The phase is similar to the ones
on Jul 24 and Aug 1 but the match isn't as good as the match between the other two days.  

What's the best way to display the best fits?  
1. Tabulate them
2. Plot minimum chisq vs period, similar to the plots Pravec makes for lightcurves.  Do this 
   regardless of the pole direction.  That is, pick the best fit for any pole direction for each
   rotation period.  Need to write another script to extract that information...  or modify jm8.pole.pl
   to keep track of it.  Yes; do the latter.  That will be easy.  Output the results to a new file.
   

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

2001 April 24 & 25

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

I modified jm8.pole.pl to record the minimum chisq for each rotation period and to output
the results to a file.  Using a period resolution of 0.1 days (2.4 h), there is a broad minimum:

Period  chisq
------  -----
5  0.380
5.1  0.343
5.2  0.299
5.3  0.250
5.4  0.211
5.5  0.179
5.6  0.155
5.7  0.137
5.8  0.125
5.9  0.109
6  0.096
6.1  0.076
6.2  0.058
6.3  0.046
6.4  0.039
6.49999999999999  0.033
6.59999999999999  0.020
6.69999999999999  0.009
6.79999999999999  0.003
6.89999999999999  0.001   <== !
6.99999999999999  0.003
7.09999999999999  0.006
7.19999999999999  0.006
7.29999999999999  0.002
7.39999999999999  0.000   <== !
7.49999999999999  0.001   <== !
7.59999999999999  0.004
7.69999999999999  0.006
7.79999999999999  0.006
7.89999999999999  0.006
7.99999999999999  0.007
8.09999999999999  0.011
8.19999999999999  0.018
8.29999999999999  0.025
8.39999999999999  0.032
8.49999999999999  0.036
8.59999999999999  0.042
8.69999999999999  0.050
8.79999999999999  0.060
8.89999999999999  0.071
8.99999999999999  0.079

Perhaps principal axis rotation will work...  We could use these periods as seeds and start 
the shape inversion.  Of course, let the rotation period float.  Or, the broadness of the minimum
(close to one day) might instead be evidence that there's no single rotation period that
matches.  I made a plot: chi2min.5deg.tpl  

The visible range extents and the bandwidths suggest a range of upper bounds on the rotation
period from about 7 days to about 21 days, assuming that the true range extent is twice the
visible range extent.  Consequently, run the calculations for a larger range of rotation periods
in both directions--say, from about 1 day to about 21 days.  

The output files are taking up a lot of space, and since /data/ast5/ is almost full, let's move
them to /data/ast1/

It turns out that time resolution of 0.05 days was overkill, so I backed off and set it = 0.1 days
and set jobs running on rhyme (p = 9.0 - 21.0 days) and reason (1.0 - 5.0 days) using 5 deg
resolution.

For the global minima it would be helpful to extract the pole coordinates--are they similar for
the different periods?  I modified jm8.pole.pl to do that.

One reasonable interpretation from work thus far is that there are pole directions and periods
that fit the data very well for the assumed diameter of 6 km and based on bandwidth measurements
from only 3 days.

Steve suggested checking the predicted bandwidth predicted from each good candidate pole direction and
rotation period against measurements from the other dates.  

Yikes.  Need the pole directions and rotation periods...  There will be a range of pole directions
for each period (not just the minimum) that works well.  This will be a large number of 
pole direction/rotation period combinations to search...  

Meanwhile, let the searches running finish, just in case there are other comparably good 
global minima.  Should we search over diameters too?  Eek... the parameter space is too large.

ideas
-----
create a list of measured bandwidths, errors, and epochs (convert to X-band as necessary)

Establish a cutoff chisq below which to consider, above which to ignore.  

Expand the chisq results retained--not just the minima because there will probably be 
  multiple pole directions per period that need to be checked

parse exsiting chisq files to create a list of candidate periods, lambdas, and betas.

For each spin state, compute bandwidths, residuals, and chisq values following Keith's lead.
  For now, assume JM8 is spherical with D = 6 km.  This is a weak link.

Test all this on a small subset of the files--the first two for example--then the 10-deg 
files, and finally the files with 5 deg resolution.  

questions
---------
1. write new code to compute bandwidths, residuals, and chisq....or input to polesrch?  
   if input to polesrch, expect chisq to increase substantially due to JM8's shape.  Note,
   however, that JM8 doesn't appear very elongated--that will help make this work.

If I simply modify existing code, save the current versions and change the name of the 
modified software.  Running the measurements back through polesrch looks like the best
way to go--save time by not duplicating Keith & Scott's code.  

Use the bandwidth from the first July 18/19 too.  The total #of bandwidths is 17.  

I already have bandwidth estimates; need to estimate uncertainties.  

More ideas
----------
Steve wants to run the best candidate PA spin states through Scott's shape software
to test for contradictions.  What he hasn't realized is that it's not just the ratios 
of the bandwidths at similar phases that matter, but also the size of the object.  

What I've done so far utilized my best guess for the diameter, namely 6 km.  Although JM8
clearly isn't spherical, it's not obviously highly elongated either--for example, the
sequence of Arecibo images, obtained when the sky motion was only a few tens of degrees,
have a ratio of the maximum to minimum bandwidth of about 1.2.  We may need to expand the
search to include a range of diameters.  

So...  forge ahead with utilizing the bandwidths from all the days first.  See if that will
enable us to narrow the space of acceptable PA spin states.  Be conservative with that
space of possible solutions so we can justify them.  Then pick at least one (or many if time
permits) to run through Scott's software by fixing the spin state and seeing if we can fit
the shape.  The quick way to do that would be to use ellipsoids.  There are a huge number
of points, so it would help to decimate the data by either ignoring the Arecibo images 
and/or averaging adjacent points (don't toss points as I did with Nyx).  

Due to the enormous size of the parameter space, drop back to 10 deg resolution in lambda
and beta.  

What's an appropriate threshold for chisg using calculations conducted thus far?  Adopt
something conservative--say, chisq large enough that the calculated bandwidths are within
some small number of standard deviations relative to the stated uncertainties.  
We could adopt the two-sigma limit...yes, that seems reasonable.  I checked the 5-deg res'n
chisq minima so far--that type of limit seems to work better than some chisq threshold, where
some values might be fine but others could be bad.  

So I need to change the search strategy of the residuals output files--instead of going
for chisq, search for examples within 2 standard deviations.  That will be straightforward
to implement.  Do this for the calculations that are already complete.  Expect multiple
"good" poles for some rotation periods and (of course) none for others.  

Doing this for all the bandwidth measurements and for a range of diameters
might not produce as many possible spin states as I originally feared.  The real question is
how meaningful it will be to use the estimated bandwidth errors given that JM8 is not
spherical. 

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

2001 April 26-29

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

I got the modified Perl script working.  It parses the residuals files to identify cases when
all the residuals/errors for a given spin state are less than a specified tolerance, and then 
the program outputs those results to a file and to the screen.  
The program is:

jm8.pole.new.pl 

Run this using the 10-deg sky search first (periods = 5 - 9 days), then start new
calculations using the viable candidates with all 18 bandwidth measurements.

I scanned the 10-deg search and saved all the poles with resid/error <= 2.5 standard
deviations.  The number is rather modest.  
file = ../10_deg/minimum.residuals.2.5sig.dat

Check the 5-deg search using periods between 6-9 days (other periods clearly fail).
...done.  
file = ../5_deg/minimum.residuals.2.5sig.dat

I also did test runs using all 18 bandwidth measurements.  In those cases, I didn't 
adopt the best matches using only 3 measurements--I simply ran the calculations
for all 18.  I used D = 6 km and p = 7, 7.5, and 8 days and 10 deg sky resolution.
I had to relax the tolerance to about 6 standard deviations to get results that
matched, leading me to suspect that there aren't going to be huge numbers of viable
pole candidates if I first use the 3 measurements as a "filter."

Range of diameters
------------------
1. Run the three points for a wider range of diameters--a range that clearly encompasses
   Deff.

2. Then run jm8.pole.new.pl on those output files to identify viable candidates.  

3. Run the viable candidates using all 18 bandwidth measurements.

Comparison of objects observed at both Arecibo and Goldstone since 1998 demonstrates
that visible range extents at Arecibo are often larger than at Goldstone due to the
higher SNR. Previously we have often assumed (with justification from the modeling)
that the true range extent is about twice the visible range extent.  If that's true,
then JM8's true range extent is between 6 and 7 km using the Goldstone images and
between 8 and 9 km using the Arecibo images.  So a safe range of diameters is between
5 - 10 km.  Let's adopt a diameter increment of 1.0 km to start; if the results
identify a lot of viable poles, then I'll improve the diameter resolution.  
(Going to higher diameter resolution will raise the issue of the size of the files--
may need to change how they're formatted.)  Start with 10-deg searches to keep 
things tractable.

Hey--to speed execution, run jobs on imagine--it has perl and it should be faster
than rhyme and reason.  It shouldn't have any problems with disk space.  imagine
would be a good place for backups too...  there's 1.12 gig of space.  Unfortunately
that won't work because Scott's software isn't available on imagine.  

CALCULATIONS
============
                            pole res'n            parse for 
d (km)  P (d)    res'n (d)    (deg)     status   3 bandwidths
------  -----    ---------  ----------  ------   ------------
5.0     4.0-9.0    0.1         10       done       done  OK
5.5     4.0-9.0    0.1         10       done       done  OK

6.0     1.0-5.0    0.1          5       done       ignore
6.0     5.0-9.0    0.1         10       done       done  OK
6.0     5.0-9.0    0.05         5       done       ignore
6.0     9.0-21.0   0.1          5       done       ignore

6.5     6.0-12.0   0.1         10       done       done  OK
7.0     6.0-12.0   0.1         10       done       done  OK
7.5     6.0-18.0   0.1         10       done       done  OK
8.0     6.0-18.0   0.1         10       done       done  OK
8.5     6.0-18.0   0.1         10       done       done  OK
9.0     6.0-18.0   0.1         10       done       done  OK
9.5     6.0-12.0   0.1         10       done       done  OK
10.0    6.0-18.0   0.1         10       done       done  OK

Check these for chisqmin as a function of diameter.
Then check for residuals below a certain threshold.

The d = 7 km and d = 8 km runs show a clear shift toward good fits with longer periods.
That is probably a simple consequence of the bandwidth equation since P and D are 
directly proportional to each other if B is constant.  So if we consider the D, P, 
chisqmin space, the minimum is a trough that's probably linear between D and P.

Go for contradictions between radar results and lightcurves: when radar results are
done, compare admissible periods from Pravec's lightcurves with radar periods.  If 
they disagree, we have another contradiction.  

April 29
--------

I modified a Perl script to parse the minimum.residuals.$tol.dat files, extract
the rotation periods, lambda, and beta, and then run those spin states through
polesrch using all 18 bandwidth measurements.  I did that for all of the 
diameters (5.5 - 10.0 km in 0.5 km increments).  Next step: make minor modifications
to the script that scans the new files to identify the best fits with normalized
residuals less than some value.

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

2001 April 30 & May 1 & 2

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

check these by rotation period too--how do they compare with Pravec's period?

New Perl script:

jm8.pole.new2.pl

Minimum normalized residuals that matches all 18 bandwidth measurements:
diameter  resid/error
--------  -----------
5.0 km     6.5
5.5 km     6.5
6.0 km     7.1
6.5 km     6.5
7.0 km     6.4
7.5 km     6.4
8.0 km     6.4
8.5 km     6.5
9.0 km     6.4
9.5 km     6.4
10.0 km    6.3

One of the surprising things about this is that the worst fitting measurement
among these best examples is from July 31, when the aspect was similar to the
one on Aug. 1.  The Aug. 1 normalized residuals are also among the largest, typically
about 4.5.  Damn!  I made a mistake--I used the wrong bandwidth on July 31, so 
of course it was off.  It's presently listed as 1.7 Hz but it should be 3.4 Hz.
I double checked ALL the days: the others are fine.  

Run polesearch.new2.pl again.  Fortunately all the software exists; just need to
crank through it and move files around.  

I wrote shell scripts to crank through the "good" cases automatically.  This should
be done within about 30 minutes.  

Minimum normalized residuals that matches all 18 bandwidth measurements:
diameter  resid/error
--------  -----------
5.0 km     2.4 !  Much smaller than before
5.5 km     2.3
6.0 km     2.3
6.5 km     2.4
7.0 km     2.4
7.5 km     2.3
8.0 km     2.3
8.5 km     2.3
9.0 km     2.4
9.5 km     2.4
10.0 km    2.3

This is working better than I expected in the sense that more poles work.  

Try to constrain the admissible PA period range and pole directions.  tabulate them.

compatible with Pravec?  What about Pravec within a factor of two?

Consistent with Scott's preliminary Deff and spin state?  Hard to believe that Scott's
preliminary results are right because the average Goldstone visible range extents are almost
as large (3.3 km) as Scott's Deff (3.4 km); average Arecibo visible range extents
are even larger: 4.2 km.  Scott stated that the shape and spin state were very preliminary;
I worry that we're putting too much stock in them.  That preliminary modeling utilized
6 images from July 20-28; among those images, the average visible range extent is 3.1 km,
(excluding the distant arc of points visible on July 24 that were confirmed on subsequent
dates) yet Scott estimates that the equivalent spherical diameter is 3.4 km.  I don't think
we should put much stock in Scott's preliminary modeling.  What his modeling _does_ 
strongly suggest is that JM8 isn't a PA rotator given that Scott's attempts to understand
the rotation state failed.

May still be useful to run calculations (full sky searches at 10 deg res'n and over a range
of periods) using just the three measurements for D as small as 3.5 km.  

lower bound on maximum dimension = 5.3 km (Aug  5)
lower bound on minimum dimension = 2.6 km (Jul 23)

CHECK SKY POSITIONS: WHAT CAN WE EXCLUDE? 

Go back to the three measurements.  Parse the files and output just the period,
lambda, and beta.  It's a 4-D space: D, P, lambda, beta.  Within each diameter directory,
could output files of lambda and beta for each admissible period and then plot them
using tkgraph.  That will be a lot of plots...  Make tables first but with less information
than the minimum*.dat files.   use jm8.pole.new.pl 

Steve and I discussed this over lunch.  We're close to the point of stopping because
it doesn't appear that we're getting much farther.  

I plotted (lambda, beta) for each diameter that I checked (5.0 - 10.0 km in 0.5 km
increments).  The admissible solutions vary as a function of rotation period, but
by inspection it is clear that there's considerable overlap as the rotation period
increases, so I plotted all the pole directions.  That meant that many were plotted
multiple times.  It quickly became obvious that the admissible pole directions occupy
the same two regions regardless of D and P, which makes sense.  As one would expect,
the solutions are separated by about 180 degrees.  Both are centered at high ecliptic
latitudes of about 60 degrees.  A modified version may be worth showing in the paper.

Plot on a globe...
first need JM8's positions in ecliptic coordinates (instead of RA and DEC).
                                      degrees
date      RA (deg) RA (h) DEC (deg) lambda beta
----      -------- ------ --------- ------ ----
Jul 18/19 186.9    12.46  59.9      149.87  54.85
    20    182.5    12.17  61.3      145.53  54.42
    21    173.5    11.57  63.5      137.80  53.23
    23    163.5    10.90  64.9      130.82  51.52
    24    146.1     9.74  65.5      120.93  47.97
    27    118.4     7.89  62.0      106.97  40.22
    28    101.4     6.76  55.6       97.60  32.45
    31     81.7     5.45  38.7       83.33  15.45
Aug  1     78.3     5.22  33.9       80.13  10.85
     2     74.8     4.99  28.4       76.65   5.65
     3     72.0     4.80  23.2       73.50   0.78
     4     69.5     4.63  18.3       70.48  -3.77
     5     67.6     4.51  14.1       68.15  -7.67
     6     65.9     4.39  10.2       65.77 -11.23
     7     64.1     4.27   6.2       63.15 -14.87
     8     63.0     4.20   3.5       61.67 -17.33
     9     62.1     4.14   1.3       60.28 -19.32

Image sequence contradiction
----------------------------
Arecibo images obtained on Aug. 4-6 show several tens of degrees of rotation between
individual days.  Using hardcopies of the Aug 5 and 6 images, a ruler, and a protractor,
the angle between the flat leading edge on the negative side of the echo rotated about
50 degrees between these two days.  The mid-epochs of those days are (UTC hours):
Aug 5 (11.97 + 13.33)/2 = 12.65
Aug 6 (12.57 + 13.07)/2 = 12.82
The difference is: (24 + 12.82) - 12.65 = 24.17 hours

That implies rotation of about (50 deg/day)*(1 day/24.2 h) = 2.1 deg/h
The Aug. 5 observations spanned 1.37 h so we might see (1.37 h)*(2.1 deg/h) = 2.7 deg
of rotation.  Sky motion between the two days was about 4 degrees so during the Aug 5 track it
was only about (4 deg)*(1.37 h)/(24 h) = 0.2 deg, which is about 12 times less than the
estimate rotation.  I grouped the first and last five runs on Aug. 5.
   There is a modest amount of rotation that appears consistent with 2-3 degrees predicted
   by the simple calculation above.   

I checked the first and last runs on Aug 5 (they're strong enough to look at without summing over
multiple runs). The Doppler frequencies of features at the positive and negative
edges differ by several bins and the leading edges of the prominent feature at positive freqs 
changed by about 9 gates (about 135 meters).  I also printed reverse grayscale
figures, made viewgraphs, and overlaid them.  The rotation is clearly evident at the locations 
mentioned above.  To my eye this rotation this rotation is comparable to that evident 
in Aug. 8 0.25 us images that spanned about 7.5 hours.  

On Aug 8 the sky motion was only about 3 deg/day.  

compare rotation in images on Aug.5 w/Aug 8 images shown at the same scale.

Another idea: if PA rotation works, we expect that (using only the 3 bandwidths obtained
at very similar orientations) on several dates we were close to the equator.  Thus,
the rotatation from day to day should be regular.  That seems to be the case between about
July 31-August 6, so perhaps those days are consistent with PA rotation.  If that's true, 
then I'm puzzled about why the July 24 and Aug. 1 images are so similar despite about 50 deg
of sky motion between those dates.   If those images are so similar, then isn't it reasonable
to expect that images on July 23 would closely resemble those obtained on July 31?  Well, 
perhaps not: there was about 12 deg of sky motion between July 23 and 24.

Aug 8 images
------------
mid epochs
file 3: (11.90 + 14.38)/2 = 13.14
file 7: (17.55 + 19.33)/2 = 18.44 
difference                   5.30 hours
If the rotation seen on Aug 5/6 also applies to Aug. 8, then we expect to see about
(2.1 deg/h)*(5.3 h) = 11 deg of rotation.  

(360 deg)/(50 deg/day) = 7.2 days  The Aug. 8 image seems to have a component of
rotation about the line of sight; have not noticed such rotation on other days.
I colored the echo edges on the view graphs and also a one prominent feature inside
the echo on Aug. 8.  That facilitates comparing the orientations.  The Aug 5 image
rotation is (apparently) mostly about the normal to the page; the rotation measured
with a protractor is about 3 degrees, in good agreement with the expectation above of
2.7 deg.  My best attempt to align the Aug 8 images worked better than I first realized--
I can match the leading edges pretty well but the elliptical feature at positive frequencies
doesn't align as well.  Using my best match, the angle between the images is about 11-12
degrees, which _is_ consistent with the expectations from Aug 5/6 assuming PA rotation.
Perhaps JM8 is a PA rotator after all.  Thus, we're left in the situation where we really
DON'T have compelling evidence for NPA rotation or even in the situation where we have
a strong suggestion of it, unless there's something else that I've missed.

Jul 31 and Aug 1 tracks span 2.5 and 3.4 h; they should be long enough to detect rotation.
They are the longest Goldstone tracks other than the one on Aug 8.  The Jul 24 track
is next longest with a duration of 1.95 h, but when I checked that earlier I couldn't 
convince myself that I could see rotation.  I just checked again: no obvious rotation.

OK, let's assume PA rotation.  Sky motion between Jul 24-Aug 1 was toward smaller RA,
that is, toward the west.  (I double checked this by looking at the April centerfold sky
chart in Sky and Telescope.)  Celestial long increases toward the east, but 
long on the globe I'm using increases the west.

We're still left with a potential discrepancy between our rotation period (ignoring sky
motion) and Pravec's: he got 5.8 days but we see almost the same phase at an interval 
of about 8 days.  Compute the mid-epochs on Jul 24 and Aug 1 to refine the interval
estimate: 
Jul 24: mid epoch = 19.0146 h doy 205 =>             205.7923
Aug  1: mid epoch = 14.1703 h doy 213 (Goldstone) => 213.5904
                                          interval =   7.7981 days
I've been playing around with models in my hands, and given that the orientation
on the two days was so similar, it looks like the sky motion was approximately parallel
to subradar latitude.  If so, then there shouldn't be much synodic rotation about the
spin axis; instead, the rotation will be about one of the other axes.  That means we 
might see features in on image near the LE or the TE that aren't evident in the other.
There seems to be a modest amount of rotation about the line of sight between images
on the two days--the Aug 1 image shows more stuff at negative frequencies.  The comparison
is hampered by the significant differences in  resolutions.  The leading edges are 
different: the Aug 1 image has an abrupt change in the LE at neg freqs but the Jul 24
image is more rounded and continuous.  There's a modest indentation on the LE close to
zero Hz on Aug 1 that isn't evident on Jul 24.  

Two other images that look very similar are those on Jul 31 and  Aug 8.  The Jul 31 
image more closely resembles the Aug 8 image than does the Aug 1 image.  That is also
an interval of about 8 days.  There is rotation evident between those two days but 
it's not about an axis perpendicular to the page; rather, it appears to be about an
axis oriented parallel to the page extending from the upper left corner to the lower
right corner.  Sky motion between Jul 31 and Aug 8 was about 35 deg; however, the 
bandwidths are nearly the same (3.35 Hz vs. 3.38 Hz).  If JM8 is a PA rotator,
that suggests the subradar latitude was very similar on both dates; perhaps it was
on opposite sides of the equator.  Sky motion
was nearly 7 deg/day on July 31 (near the peak for this object) but only about 3 deg/d
on Aug. 8.  Sky motion between Jul 31 and Aug 8 was about 35 deg.

Following the logic of the last paragraph, we might expect the Aug 1 and Aug 9 images
to be very similar.  It's possible to match features in both but there has been
substantial rotation about an axis roughly parallel to the page and bisecting the echo 
through the middle of the LE.  

Can we reconcile our rotation period with Pravec's?  Before the radar experiment began
Sarounova and Pravec estimated the period was roughly 12-13 days.  At that time Pravec 
stated that a ~7 day period was unlikely.  Later, but still before radar observations
began, Pravec emailed again that his best estimate for the period was 7.6 +/- 0.2 days.
He also stated then that he couldn't rule out twice that period (15.2 days).  On the
UTC day that radar observations began Pravec revised the estimated period to 14.1+/-0.5
days; in this case, the lightcurve has two peaks.  
Shortly after the experiment ended Pravec estimated P = 6.76+/-0.2 days on the website.  
In the winter of 2000 he estimated P = 5.7 days
and now he estimates P = 5.8 +/-0.06 days.  The data he's using were obtained between
1999 July 3.0-21.9 UTC at high solar phase angles.  There is also one night availble 
from Aug. 16 that Pravec did not include.  The P = 5.8 d period has three minima/maxima
per period.  Based on the appearance of JM8 in the images on July 24, 31, Aug 1, and 
Aug 8 I don't see how P = 5.8 d  or P > 12 d can be correct, but P = 7.6 days 
seems plausible.  

Can we reconcile the early images with the images after July 31?  Rotation from Jul 23
to 24 seems reasonable but I don't understand July 27-28.  One might be able to match
features if the apparent rotation was close to 90 degrees, which is larger than rotation
evident on other days.  How might that come about?  Sky motion between the observations
on Jul 27 and 28 was about 13 deg despite _daily_ sky motion of only about 6-7 deg.  
The reason is that the mid epoch of the Jul 27 was at 2.5 h UTC and the mid epoch on
Jul 28 was at about 18.25, a difference of about 40 hours or nearly two days.  Consequently,
if the rotation of about 50 deg seen on other days is correct, then we should have
observed about 80 deg of rotation.  Sky motion could easily account for the rest.

The situation on Jul 20/21 is similar to the situation just described for Jul 27-28
in that the difference between the mid epochs was closer to two days than to one day.
Jul 20 mid epoch =  3.67 UT
Jul 21 mid epoch = 18.425 UT
difference = 38.8 hours.  
It's tough to tell on those two days--the Jul 20 image is weak and we can't see much
other than gross shape attributes.  

What about the similarity between July 24 and Aug 1?  It's puzzling.  

If JM8 is a PA rotator, that will simplify the shape inversion considerably...and we
might be able to do it without much help from Scott.  How much did Scott really work on this 
object?  He never really indicated... The initial suspicion of NPA rotation came about
1) because the rotation was slow and 2) there weren't that many images when Scott 
started and 3) the correspondence among them was difficult to notice.  If the rotation 
period is close to 8 days then the 6 images Scott used in his preliminary shape inversion
should have covered most of the object's surface area.  

If I were going to invert the shape, I'd start with ellipsoids
and explore a range of slow rotation periods from somewhat less than Pravec's to 

Jul 28 (doy 209) data span about 1.5 h--perhaps that's enough to see rotation.

- - - - - - - - - - 

I presented this to Steve.  He commented that NPA rotation is difficult to prove but that
the evidence for PA rotation looks strong.  If JM8 is a PA rotator, and if the Arecibo
observations straddle the equator as I think they do, then that means we can do a hull
estimation.  We did a quick first pass at that by copying the images that were prepared
at the same scale, cutting them out, aligning them on top of each other, and taping them
down.  That gives a first pass pole-on silhouette.  The elongation is rather modest,
much of the silhouette is rounded, there's a prominent protrusion, and adjacent to the
protrusion there's a large planar feature in the silhouette.  So it looks like Ellen Howell
was on the right track with her first pass at JM8 last fall.  I wish we had gone through 
the exercise in January that we just did because if we had we might have a 3D shape model
by now.  Publishing this paper strongly suspecting PA rotation but not including the 
shape model may not go over well--the question may arise why we didn't include the model
in the paper.  

Steve took a first pass at the km/Hz conversion estimated from the silhouette.  Need to
refine that -- we want better estimates of Deff and P.

Hey--use Scott's software radpole/radgeo (whatever the correct name is) to try different
periods, predict longitudes, etc.  By concentrating on the days when the subradar latitude
was apparently close to equatorial it may be possible to narrow the range of admissible 
sidereal rotation periods.  

Steve also suggested using an a posteriori ephemeris to locate the ephemeris range and
Doppler in each image and see how it evolves from day to day.  If the COM rotates then
there's a problem.  Jon said he would provide one by May 4.  

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

2001 May 3 & 4

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

Scott handed off the JM8 modeling to me in December, 2000.  He provided a pgm file that shows
images, modeled images, and POS views.  The July 24 and August 1 images are so similar that
the POS views of the asteroid should also be almost the same, but they aren't.  TILT.
Scott's modeling had NPA rotation--the spin file clearly shows rotation about all
three axes.  What was going on?  Maybe Scott wasn't paying much attention...

- - - - - - - - - - - - - - - 

Use similar delay-Doppler images on different days to constrain the rotation period
-----------------------------------------------------------------------------------
              mid epoch mid epoch  interval sky motion
date     doy   UTC h     UTC days   (days)    (deg)
----     ---  --------  ---------  -------- ----------
Jul 24   205  19.0146   205.7923    7.76       ~50
Aug  1   213  13.3718   213.5572

Jul 31   212  18.6713   212.7780    7.77       ~35
Aug  8   220  13.1367   220.5474 

The orientations of the images aren't perfect matches on these pairs of days but
these results are close enough to suggest strongly that we're in the right ballpark.
The true sidereal rotation period could easily be a few tens of a day in either
direction.  ==> Use Scott's software to refine this estimate.

For radar observations spanning significant sky motion, which is the case here, the
sidereal rotation period and pole direction are coupled.  

The question is how...  polesrch will take input rotation periods, diameters,
pole directions, and bandwidth measurements and compute residuals and chisq.  

consider rdfphase too--it seems less complicated and it assigns rotation phases to 
cw rdf files...which we have on July 24, 31, and Aug 1 (but not on Aug 8).  One 
could try to get the rotation phases to match.  I'm unaware of other software that
outputs rotation phase (longitude).  Presumably rdfphase utilizes Scott's software. 

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 73 > rdfphase
Usage:  rdfphase -i infile -o outfile -e ephemeris_file -E epoch -l pole_lon -L pole_lat -b bias -p period -t time_tag [-h]

-i   infile          specifies the name of the input file,
                     a '-' implies the use of stdin
-o   outfile         specifiles the name of the output file
                     a '-' implies the use of stdout
-e   eph_file        Ephemeris File
-t   time_tag        time_tag to use for spectrum times (defaults
                     to rcsta)
-b   bias            Value to add (seconds) to all spectrum times
-E   epoch           Epoch (yyyy/mm/dd/hh:mm:ss)
-p   period          sidereal spin period (hours)
-l   pole_lon        Pole Longitude in ecliptic coordinates
-L   pole_lat        Pole Latitude in ecliptic coordinates
-h                   help

radgeo should work too but something is wrong:

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 74 > radgeo
usage - radgeo ephemeris_file times_file output_file

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 75 > radgeo jm8.ephem.7.8 jm8.epochs.test results.dat
ERROR: time is out of ephemeris time base

I don't understand--the ephemeris begins on July 16 and ends on August 12, dates that are well
outside the ones in the epochs file.

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 76 > cat jm8.epochs.test
4 {number of lines below}
{YY  MO DD HH MM SS  BB  er}

1999  7 24 19  1  0  1.7 0.15 
1999  7 31 18 41  0  1.7 0.15 
1999  8  1 14 16  0  3.3 0.1  
1999  8  8 15 37  0  3.4 0.15 

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 77 > cat results.dat 
           JD   YY MO DD HH MM SS     LAT     LON   PHASE    RATE
 11384.292361 1999  7 24 19  1  0   67.50  152.84  207.16   17.22

Here's an excerpt of the ephemeris file:  

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 78 > more jm8.ephem.7.8 
310                      {hudson pole longitude (degrees)}
-70                      {hudson pole latitude (degrees) }
187.2                      {hudson spin period (hours)     }

1999 07 18 00 00 00     {reference time YY MO DD HH MM SS min before obs }
                        { ref time is when x axis crosses ecliptic       }
649                     {number of entries below                         }

{YY  MO DD HH  RA       DEC       DIST}
 1999 07 16 00      195.52896  56.13293  0.1170670631
 1999 07 16 01      195.43463  56.17974  0.1168126500
.
.
.
 1999 08 11 21       59.90391  -4.03706  0.1045380884
 1999 08 11 22       59.87274  -4.11641  0.1047871351
 1999 08 11 23       59.84291  -4.19541  0.1050354250
 1999 08 12 00       59.81424  -4.27411  0.1052824184

Perhaps try different zero-phase epochs?  

1999 07 19 00 00 00  ==> same error
1999 07 16 00 00 00  ==> same error
1999 07 20 00 00 00  ==> same error
1999 07 24 00 00 00  ==> same error

Perhaps the ephemeris needs even more days on either side of the epochs file?
I expanded the dates to July 10 and August 18.  When I ran radgeo I got a new 
error message:

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 106 > radgeo jm8.ephem.test jm8.epochs.test results.dat
ERROR: no valid string available

OK, that error was caused because I had the wrong number of lines in the ephemeris file
header relative to the number that were actually there.  When I fixed it I recovered the
other error.

This isn't working so try using rdfphase instead.
I checked a version of the source code in: 
reason:/dev1/rosema/release/src/rdfprogs/rdfphase.cc
Yikes!  This is a complicated program but it appears to do everything on its own
without invoking Scott's software.  rdfphase.cc was written by Keith.

reason:/data/ast5/1999JM8/proc/cw/new_cw_files/99205.512.file.rdf
reason:/data/ast5/1999JM8/proc/cw/new_cw_files/99213.512.file.rdf

This works but it's really slow.  Steve and I discussed this over lunch--he suggested
using radpole: its output includes the subradar latitudes _and_ longitudes and so 
is more useful than rdfphase.  

- - - - - - - - - - -  - - - - - - - - - - - - - 

Try using radpole directly (w/o polesrch).
==========================================

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 157 > radpole
radpole.c - version 2.0 May 1, 1998
            5/1/98  - rosema - fixed bug where inputs not converted to radians
            2/25/98 - rosema - modified (again) to allow input of the pole
                               on the command line, to accept and pass extra
                               data.
usage - radpole ephemeris_file epoch_file output_file pole_lon pole_lat

Radpole doesn't check to see if the bandwidths work, it simply takes the input
information and computes the subradar latitude and longitude and rotation rate.

I used poles I found in my search using D = 7.0 km, P = 9.0 days.  The pole directions
were pretty consistent over all the periods I searched and over all the diameters.
I chose this period because it gave the most candidates for this diameter.

Here are the poles I checked:

lambda beta
100 80
110 80
120 80
130 70
130 80
140 70
140 80
150 40 
150 50  <== best candidates
150 60  <== 
150 70
160 40  
160 50  <-
160 60  <==
160 70

280 -80 
290 -80

300 -80
310 -10
310 -20
310 -80
320 -10
320 -20
320 -80
40 70
50 60
50 70
60 60
60 70
70 70
70 80
80 70
80 80
90 70
90 80

Here are the best pole directions by far using P = 7.8 days:

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 256 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 150 50
reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 257 > cat results.dat
           JD   YY MO DD HH MM SS     LAT     LON    RATE      BW     ERR
 11384.292361 1999  7 24 19  1  0  -70.82  318.29   19.43    1.70    0.15
 11392.094444 1999  8  1 14 16  0  -21.13  331.85   42.40    3.30    0.10
 11399.150694 1999  8  8 15 37  0   12.19   10.26   44.43    3.40    0.15
reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 258 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 150 60
reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 259 > cat results.dat
           JD   YY MO DD HH MM SS     LAT     LON    RATE      BW     ERR
 11384.292361 1999  7 24 19  1  0  -69.27  345.86   19.80    1.70    0.15
 11392.094444 1999  8  1 14 16  0  -19.33  335.49   44.21    3.30    0.10
 11399.150694 1999  8  8 15 37  0   14.18    7.96   44.58    3.40    0.15

Need to explore more pole directions and periods.

Other candidates:
reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 279 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 160 50
reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 280 > cat results.dat
           JD   YY MO DD HH MM SS     LAT     LON    RATE      BW     ERR
 11384.292361 1999  7 24 19  1  0  -64.46  312.78   24.13    1.70    0.15
 11392.094444 1999  8  1 14 16  0  -14.73  324.01   43.89    3.30    0.10
 11399.150694 1999  8  8 15 37  0   18.54    2.87   43.02    3.40    0.15

reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 281 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 160 60
reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 282 > cat results.dat
           JD   YY MO DD HH MM SS     LAT     LON    RATE      BW     ERR
 11384.292361 1999  7 24 19  1  0  -64.48  333.89   23.47    1.70    0.15
 11392.094444 1999  8  1 14 16  0  -14.38  326.62   45.26    3.30    0.10
 11399.150694 1999  8  8 15 37  0   19.15  359.45   43.41    3.40    0.15

OK, after doing this multiple times it's clear I need to write a script to run through
the permutations.  Do it in Perl: use different output file names...  or take each output
file, store it, the period, lambda, and beta, and then output everything at the end into
a new file.  Since computer time is cheap, do this over the whole sky and over a range 
of rotation periods.  Then scan the results visually for cases that worked.  The key 
thing is to look for longitudes that are very similar on July 24 and Aug 1, a longitude
on Aug. 8 that is within a few tens of deg of the other two; very similar subradar latitudes on Aug 1
and 8 (probably on either side of the equator), and a high subradar latitude (either N or S)
on July 24.  

read in an ephem file template and store it in an array

loop over rotation periods: use small time resolution; say, 0.5 h

loop over latitudes (5 deg res'n)
  
loop over longitudes (5 deg res'n)

update the period & output it to a new ephem file--use the same ephem file name to avoid 
  creating tons of new files that take up a lot of space

run radpole using the same output name each time

read the radpole output file and append it to another file that contains all the outputs: 
  system("cat results.dat >> all_results.dat");
also write the pole direction, lambda, and beta to the big output file.

end of loops

Perl script: jm8.radpolesearch.pl

I set it running on rhyme to scan periods between 5.0 and 9.0 days at 0.1 day intervals
and to search the entire sky for each period at 5 deg intervals in lambda and beta.
This will may take a few hours.  
One problem with this approach is that radpole (of course) doesn't output the residuals
for the bandwidths computed from each pole direction.  So it will be possible to get
longitudes and latitudes that fit the expected pattern but the bandwidths may not match.
The unknown factor is the diameter.  So... we could return to the previous searches using
different diameters, periods, and pole directions (using finer resolution for the sky
search, diameters, and periods).   Or... proceed as we are now, parse the results for 
admissible spin states, and then run them through polesrch as a function

parse the output file for examples when the July 24 and August 1 longitudes are close to
each other and when the longitude on August 8 isn't more than a few tens of degrees from
either of the other two.  The Jul 24 lat should be high and the other two should be close
to and straddle the equator, but it may not be necessary to search for that.

I'm working in reason:/data/ast5/1999JM8/analysis/pole_search/temp2

Goals: rotation period
       pole direction
       km/Hz conversion
       pole-on silhouette of JM8--not just the hull.  Similar to Geographos.

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

2001 May 6 & 7

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

Parse the output text file
--------------------------
There are groups of 5 lines per spin state.  

open results.dat
stick it in an array
close the file
get the number of lines in the file

for($i = 1; $i <= $num; $i=$i+5)  # Parse in groups of four lines
get the period, lambda, and beta
get the lat and long computed for each epoch
if the first two longitudes match within about 15 deg, then check the third
 one.  If it's within about 50 deg of the other two, then save it and output
 the results.  Inspect the latitudes to see if they work; if not, increase the
 sophistication of the parsing.

 output the spin state, longitudes, and latitudes 

Of course, there are instances where the longitudes on July 24 and Aug 1 are similar
but they cross the 360 deg boundary, so I modified the code to deal with that and
to deal with having the third longitude across the boundary.  

Searching over all the cases that I started on Friday (5 deg spacing, 0.1 day res'n,
periods between 5.0 and 9.0 days), there are 8100 matches based solely on the 
longitudes.  To determine which spin states work, we need to compute bandwidths and
that requires that we estimate diameters.  So... for each spin state, run polesrch
through a range of diameters to search for ones that produce acceptable bandwidth
residuals.  Ugh!  Won't this ever end?   Note that so far I haven't made use of
the subradar latitudes...  

First, impose latitude restrictions: delta 1 (Jul 24) needs to be >= 60 deg so the 
bandwidth ratios can equal 0.5.  That will exclude many cases and save time.  That
shrinks the possibilities considerably.  

Also search over ratios of cos(delta) on Jul 24 and Aug 1 within a specified range.
Use raterr to determine the bounds:
reason:/data/ast5/1999JM8/analysis/pole_search/temp2/5_deg_search < 560 > /home/ostro/bin/raterr
ENTER OUTPUT FORMAT.  (E/F)
f
ENTER:  X1,EX1, X2,EX2, CC
1.73, 0.15, 3.27, 0.15, 0.0
        0.478  <  RATIO  <         0.582
 RATIO =        0.529  PLUS        0.053  MINUS         0.051

I am not sure I did that correctly--what is CC?  Steve's documentation is cryptic.

reason:/data/ast5/1999JM8/analysis/pole_search/temp2/5_deg_search < 563 > /home/ostro/bin/raterr
ENTER OUTPUT FORMAT.  (E/F)
f
ENTER:  X1,EX1, X2,EX2, CC
1.73, 0.15, 3.27, 0.10, 0.0
        0.481  <  RATIO  <         0.578
 RATIO =        0.529  PLUS        0.049  MINUS         0.048

ENTER:  X1,EX1, X2,EX2, CC
1.73, 0.15, 3.27, 0.10, 1.0
        0.498  <  RATIO  <         0.558
 RATIO =        0.529  PLUS        0.029  MINUS         0.031

0.48 <= ratio <= 0.60 looks safe.

Implementing this in combination with the other constraints narrowed the acceptable
spin states from 8100 to 513.  At present I don't deal with the bandwidth ratios 
between Aug 1 and 8.  Their ratio is 3.27/3.38 = 0.97.  A difference of more than 
about 6% would be significant...

ENTER OUTPUT FORMAT.  (E/F)
f
ENTER:  X1,EX1, X2,EX2, CC
3.27, 0.15, 3.38, 0.15, 0.0
        0.908  <  RATIO  <         1.031
 RATIO =        0.967  PLUS        0.064  MINUS         0.060

Let's build this in too... that excludes a lot more cases.  Now there are only 241.

The periods extend from 6.6 - 7.5 days and 8.1 - 8.5 days.  Those periods exclude 
my estimate by inspection of 7.8 days and Pravec's estimate of 5.8 days from 
lightcurves.  

The minimum subradar
latitude on July 24 that is admissible is about 56 degrees.  The maximum 
subradar latitude (in absolute value) is about 63 degrees.  As expected, the latitudes
on Aug 1 and 8 are on opposite sides of the equator.

Plot the candidate pole directions.  Use grace and read in as block data.  
reason:/data/ast5/1999JM8/analysis/pole_search/temp2/5_deg_search/jm8.poles.grace
The poles are very similar to the ones I identified earlier but their distribution
is somewhat smaller.  

Next step: run polesrch for each spin state over a range of diameters.  Our constraints
on the diameter and bandwidths should be sufficient to rule out some of the spin states.

Thus far I am not using bandwidths on any of the other days.  The results to date indicate
that the subradar latitude was close to the equator during the Arecibo observations,
so we could use the bandwidths directly...  they vary from 3.1 to 3.6, implying a pole-on
elongation of about 1.2.  Save this idea for later.

Here are the admissible spin states:

From left to right, the values tabulated are:

                 subradar          subradar
    lambda    <--latitude-----> <--longitude---->
P (d)    beta  7/24  8/1   8/8  7/24   8/1   8/8
-----    ----  ----  ---   ---  ----   ---   ---
6.60  150  25 -57.5 -22.6   5.8 264.3 249.5 242.8 
6.60  260 -75  58.0  25.8  -3.1 351.1 341.1 333.9 
6.60  265 -75  59.1  25.8  -3.5 357.2 346.6 338.6 
6.60  270 -75  60.0  25.6  -4.1   3.5 352.0 343.4 
6.60  275 -75  60.9  25.3  -4.7  10.1 357.5 348.1 
6.70  150  25 -57.5 -22.6   5.8 265.0 256.5 255.6 
6.70  150  30 -61.3 -22.7   7.2 270.5 258.6 255.0 
6.70  260 -75  58.0  25.8  -3.1 351.7 348.1 346.6 
6.70  265 -75  59.1  25.8  -3.5 357.8 353.6 351.4 
6.70  270 -80  56.2  20.6  -8.5   9.4 358.6 356.4 
6.70  270 -75  60.0  25.6  -4.1   4.2 359.0 356.1 
6.70  275 -80  56.7  20.5  -9.0  15.4   3.9   1.2 
6.70  275 -75  60.9  25.3  -4.7  10.7   4.5   0.9 
6.70  280 -80  57.1  20.2  -9.4  21.5   9.1   6.0 
6.70  280 -75  61.6  24.8  -5.4  17.5   9.9   5.6 
6.70  285 -80  57.5  19.8 -10.0  27.7  14.3  10.8 
6.70  285 -75  62.1  24.3  -6.2  24.5  15.2  10.3 
6.70  290 -80  57.7  19.4 -10.6  33.9  19.5  15.6 
6.70  290 -75  62.6  23.7  -7.1  31.7  20.6  15.1 
6.70  295 -75  62.8  22.9  -8.1  39.0  25.9  19.8 
6.80  150  25 -57.5 -22.6   5.8 265.6 263.3 267.9 
6.80  150  30 -61.3 -22.7   7.2 271.1 265.4 267.4 
6.80  155  30 -58.3 -18.4  11.4 273.9 262.9 265.1 
6.80  260 -75  58.0  25.8  -3.1 352.3 354.9 359.0 
6.80  265 -75  59.1  25.8  -3.5 358.4   0.4   3.7 
6.80  270 -80  56.2  20.6  -8.5  10.0   5.4   8.7 
6.80  270 -75  60.0  25.6  -4.1   4.8   5.8   8.5 
6.80  275 -80  56.7  20.5  -9.0  16.0  10.7  13.6 
6.80  275 -75  60.9  25.3  -4.7  11.4  11.2  13.2 
6.80  280 -80  57.1  20.2  -9.4  22.1  15.9  18.4 
6.80  280 -75  61.6  24.8  -5.4  18.2  16.6  18.0 
6.80  285 -80  57.5  19.8 -10.0  28.3  21.1  23.2 
6.80  285 -75  62.1  24.3  -6.2  25.2  22.0  22.7 
6.80  290 -80  57.7  19.4 -10.6  34.5  26.3  28.0 
6.80  290 -75  62.6  23.7  -7.1  32.3  27.4  27.4 
6.80  295 -80  57.9  18.9 -11.3  40.8  31.5  32.8 
6.80  295 -75  62.8  22.9  -8.1  39.6  32.6  32.1 
6.80  300 -80  57.9  18.4 -12.0  47.1  36.6  37.6 
6.80  300 -75  62.9  22.1  -9.1  47.0  37.9  36.8 
6.80  305 -80  57.9  17.8 -12.7  53.4  41.8  42.4 
6.80  305 -75  62.9  21.2 -10.2  54.3  43.1  41.5 
6.80  310 -80  57.8  17.1 -13.5  59.7  46.9  47.3 
6.80  310 -75  62.7  20.2 -11.4  61.6  48.2  46.3 
6.80  315 -80  57.6  16.4 -14.3  66.0  51.9  52.1 
6.90  150  25 -57.5 -22.6   5.8 266.2 269.9 279.9 
6.90  150  30 -61.3 -22.7   7.2 271.7 272.0 279.4 
6.90  155  30 -58.3 -18.4  11.4 274.5 269.5 277.1 
6.90  155  35 -61.6 -18.5  12.5 281.1 271.2 276.1 
6.90  160  30 -55.1 -14.1  15.6 276.5 267.1 274.8 
6.90  160  35 -58.3 -14.4  16.6 282.4 268.4 273.4 
6.90  260 -75  58.0  25.8  -3.1 352.9   1.5  11.0 
6.90  265 -75  59.1  25.8  -3.5 359.1   7.0  15.8 
6.90  270 -80  56.2  20.6  -8.5  10.6  12.0  20.8 
6.90  270 -75  60.0  25.6  -4.1   5.4  12.4  20.5 
6.90  275 -80  56.7  20.5  -9.0  16.6  17.3  25.6 
6.90  275 -75  60.9  25.3  -4.7  12.0  17.9  25.2 
6.90  280 -80  57.1  20.2  -9.4  22.7  22.5  30.4 
6.90  280 -75  61.6  24.8  -5.4  18.8  23.2  30.0 
6.90  285 -80  57.5  19.8 -10.0  28.9  27.7  35.2 
6.90  285 -75  62.1  24.3  -6.2  25.8  28.6  34.7 
6.90  290 -80  57.7  19.4 -10.6  35.1  32.9  40.0 
6.90  290 -75  62.6  23.7  -7.1  32.9  34.0  39.4 
6.90  295 -80  57.9  18.9 -11.3  41.4  38.1  44.8 
6.90  295 -75  62.8  22.9  -8.1  40.2  39.2  44.1 
6.90  300 -80  57.9  18.4 -12.0  47.7  43.2  49.6 
6.90  300 -75  62.9  22.1  -9.1  47.6  44.5  48.9 
6.90  305 -80  57.9  17.8 -12.7  54.0  48.4  54.5 
6.90  305 -75  62.9  21.2 -10.2  54.9  49.7  53.6 
6.90  310 -80  57.8  17.1 -13.5  60.3  53.5  59.3 
6.90  310 -75  62.7  20.2 -11.4  62.2  54.8  58.3 
6.90  315 -80  57.6  16.4 -14.3  66.6  58.5  64.1 
6.90  315 -75  62.3  19.1 -12.6  69.4  59.9  63.0 
6.90  320 -80  57.2  15.7 -15.1  72.8  63.6  69.0 
6.90  320 -75  61.8  18.0 -13.8  76.5  64.9  67.7 
6.90  325 -80  56.9  14.9 -16.0  78.9  68.6  73.9 
6.90  325 -75  61.1  16.8 -15.1  83.3  69.9  72.5 
6.90  330 -80  56.4  14.1 -16.8  84.9  73.6  78.8 
6.90  335 -80  55.8  13.2 -17.7  90.8  78.6  83.7 
6.90  340 -80  55.2  12.4 -18.6  96.6  83.6  88.6 
6.90  345 -80  54.5  11.5 -19.4 102.3  88.5  93.6 
7.00  150  25 -57.5 -22.6   5.8 266.8 276.3 291.6 
7.00  150  30 -61.3 -22.7   7.2 272.3 278.4 291.1 
7.00  155  30 -58.3 -18.4  11.4 275.1 275.9 288.7 
7.00  155  35 -61.6 -18.5  12.5 281.6 277.6 287.7 
7.00  160  30 -55.1 -14.1  15.6 277.1 273.5 286.5 
7.00  160  35 -58.3 -14.4  16.6 283.0 274.8 285.1 
7.00  160  40 -61.0 -14.6  17.4 290.2 276.1 283.5 
7.00  260 -75  58.0  25.8  -3.1 353.5   7.9  22.6 
7.00  265 -75  59.1  25.8  -3.5 359.6  13.4  27.4 
7.00  270 -80  56.2  20.6  -8.5  11.2  18.4  32.4 
7.00  270 -75  60.0  25.6  -4.1   6.0  18.8  32.2 
7.00  275 -80  56.7  20.5  -9.0  17.2  23.7  37.2 
7.00  275 -75  60.9  25.3  -4.7  12.6  24.2  36.9 
7.00  280 -80  57.1  20.2  -9.4  23.3  28.9  42.0 
7.00  280 -75  61.6  24.8  -5.4  19.4  29.6  41.6 
7.00  285 -80  57.5  19.8 -10.0  29.5  34.1  46.8 
7.00  285 -75  62.1  24.3  -6.2  26.4  35.0  46.4 
7.00  290 -80  57.7  19.4 -10.6  35.7  39.3  51.6 
7.00  290 -75  62.6  23.7  -7.1  33.5  40.4  51.1 
7.00  295 -80  57.9  18.9 -11.3  42.0  44.5  56.5 
7.00  295 -75  62.8  22.9  -8.1  40.8  45.6  55.8 
7.00  300 -80  57.9  18.4 -12.0  48.3  49.6  61.3 
7.00  300 -75  62.9  22.1  -9.1  48.1  50.9  60.5 
7.00  305 -80  57.9  17.8 -12.7  54.6  54.8  66.1 
7.00  305 -75  62.9  21.2 -10.2  55.5  56.1  65.2 
7.00  310 -80  57.8  17.1 -13.5  60.9  59.9  70.9 
7.00  310 -75  62.7  20.2 -11.4  62.8  61.2  69.9 
7.00  315 -80  57.6  16.4 -14.3  67.2  64.9  75.8 
7.00  315 -75  62.3  19.1 -12.6  70.0  66.3  74.7 
7.00  320 -80  57.2  15.7 -15.1  73.3  70.0  80.7 
7.00  320 -75  61.8  18.0 -13.8  77.1  71.3  79.4 
7.00  325 -80  56.9  14.9 -16.0  79.5  75.0  85.5 
7.00  325 -75  61.1  16.8 -15.1  83.9  76.3  84.2 
7.00  330 -80  56.4  14.1 -16.8  85.5  80.0  90.4 
7.00  330 -75  60.3  15.6 -16.3  90.6  81.3  88.9 
7.00  335 -80  55.8  13.2 -17.7  91.4  85.0  95.3 
7.00  335 -75  59.4  14.3 -17.6  97.0  86.2  93.7 
7.00  340 -80  55.2  12.4 -18.6  97.2  90.0 100.3 
7.00  340 -75  58.4  13.0 -18.9 103.2  91.1  98.6 
7.00  345 -80  54.5  11.5 -19.4 102.9  94.9 105.2 
7.10  150  30 -61.3 -22.7   7.2 272.9 284.6 302.4 
7.10  155  30 -58.3 -18.4  11.4 275.7 282.1 300.1 
7.10  155  35 -61.6 -18.5  12.5 282.2 283.8 299.1 
7.10  160  30 -55.1 -14.1  15.6 277.7 279.7 297.8 
7.10  160  35 -58.3 -14.4  16.6 283.6 281.0 296.4 
7.10  160  40 -61.0 -14.6  17.4 290.8 282.3 294.9 
7.10  270 -80  56.2  20.6  -8.5  11.8  24.7  43.8 
7.10  275 -80  56.7  20.5  -9.0  17.8  29.9  48.6 
7.10  280 -80  57.1  20.2  -9.4  23.9  35.1  53.4 
7.10  285 -80  57.5  19.8 -10.0  30.1  40.3  58.2 
7.10  285 -75  62.1  24.3  -6.2  26.9  41.2  57.7 
7.10  290 -80  57.7  19.4 -10.6  36.3  45.5  63.0 
7.10  290 -75  62.6  23.7  -7.1  34.1  46.6  62.4 
7.10  295 -80  57.9  18.9 -11.3  42.6  50.7  67.8 
7.10  295 -75  62.8  22.9  -8.1  41.4  51.9  67.1 
7.10  300 -80  57.9  18.4 -12.0  48.9  55.9  72.6 
7.10  300 -75  62.9  22.1  -9.1  48.7  57.1  71.8 
7.10  305 -80  57.9  17.8 -12.7  55.2  61.0  77.5 
7.10  305 -75  62.9  21.2 -10.2  56.1  62.3  76.6 
7.10  310 -80  57.8  17.1 -13.5  61.5  66.1  82.3 
7.10  310 -75  62.7  20.2 -11.4  63.4  67.4  81.3 
7.10  315 -80  57.6  16.4 -14.3  67.7  71.2  87.1 
7.10  315 -75  62.3  19.1 -12.6  70.6  72.5  86.0 
7.10  320 -80  57.2  15.7 -15.1  73.9  76.2  92.0 
7.10  320 -75  61.8  18.0 -13.8  77.6  77.6  90.7 
7.10  325 -80  56.9  14.9 -16.0  80.0  81.2  96.9 
7.10  325 -75  61.1  16.8 -15.1  84.5  82.6  95.5 
7.10  330 -80  56.4  14.1 -16.8  86.1  86.2 101.8 
7.10  330 -75  60.3  15.6 -16.3  91.2  87.5 100.3 
7.10  335 -80  55.8  13.2 -17.7  92.0  91.2 106.7 
7.10  335 -75  59.4  14.3 -17.6  97.6  92.4 105.1 
7.10  340 -80  55.2  12.4 -18.6  97.8  96.2 111.6 
7.10  340 -75  58.4  13.0 -18.9 103.8  97.3 109.9 
7.10  340 -70  61.1  13.6 -19.1 111.0  98.5 108.2 
7.10  345 -80  54.5  11.5 -19.4 103.5 101.1 116.6 
7.20  155  30 -58.3 -18.4  11.4 276.2 288.2 311.1 
7.20  155  35 -61.6 -18.5  12.5 282.8 289.9 310.1 
7.20  160  30 -55.1 -14.1  15.6 278.2 285.8 308.8 
7.20  160  35 -58.3 -14.4  16.6 284.2 287.0 307.4 
7.20  160  40 -61.0 -14.6  17.4 291.4 288.3 305.9 
7.20  290 -80  57.7  19.4 -10.6  36.9  51.6  74.0 
7.20  295 -80  57.9  18.9 -11.3  43.1  56.8  78.8 
7.20  300 -80  57.9  18.4 -12.0  49.4  61.9  83.6 
7.20  300 -75  62.9  22.1  -9.1  49.3  63.1  82.9 
7.20  305 -80  57.9  17.8 -12.7  55.8  67.0  88.5 
7.20  305 -75  62.9  21.2 -10.2  56.6  68.3  87.6 
7.20  310 -80  57.8  17.1 -13.5  62.0  72.1  93.3 
7.20  310 -75  62.7  20.2 -11.4  64.0  73.5  92.3 
7.20  315 -80  57.6  16.4 -14.3  68.3  77.2  98.2 
7.20  315 -75  62.3  19.1 -12.6  71.2  78.6  97.0 
7.20  320 -80  57.2  15.7 -15.1  74.5  82.3 103.0 
7.20  320 -75  61.8  18.0 -13.8  78.2  83.6 101.8 
7.20  325 -80  56.9  14.9 -16.0  80.6  87.3 107.9 
7.20  325 -75  61.1  16.8 -15.1  85.1  88.6 106.5 
7.20  330 -80  56.4  14.1 -16.8  86.6  92.3 112.8 
7.20  330 -75  60.3  15.6 -16.3  91.7  93.6 111.3 
7.20  335 -80  55.8  13.2 -17.7  92.5  97.3 117.7 
7.20  335 -75  59.4  14.3 -17.6  98.1  98.5 116.1 
7.20  340 -80  55.2  12.4 -18.6  98.4 102.2 122.6 
7.20  340 -75  58.4  13.0 -18.9 104.3 103.4 120.9 
7.20  340 -70  61.1  13.6 -19.1 111.5 104.5 119.2 
7.20  345 -80  54.5  11.5 -19.4 104.1 107.2 127.6 
7.30  155  35 -61.6 -18.5  12.5 283.3 295.8 320.8 
7.30  160  30 -55.1 -14.1  15.6 278.8 291.7 319.5 
7.30  160  35 -58.3 -14.4  16.6 284.7 292.9 318.1 
7.30  160  40 -61.0 -14.6  17.4 291.9 294.2 316.6 
7.30  310 -75  62.7  20.2 -11.4  64.5  79.4 103.0 
7.30  315 -80  57.6  16.4 -14.3  68.8  83.1 108.9 
7.30  315 -75  62.3  19.1 -12.6  71.7  84.5 107.7 
7.30  320 -80  57.2  15.7 -15.1  75.0  88.2 113.7 
7.30  320 -75  61.8  18.0 -13.8  78.7  89.5 112.5 
7.30  325 -80  56.9  14.9 -16.0  81.1  93.2 118.6 
7.30  325 -75  61.1  16.8 -15.1  85.6  94.5 117.2 
7.30  330 -80  56.4  14.1 -16.8  87.2  98.2 123.5 
7.30  330 -75  60.3  15.6 -16.3  92.2  99.5 122.0 
7.30  335 -80  55.8  13.2 -17.7  93.1 103.2 128.4 
7.30  335 -75  59.4  14.3 -17.6  98.7 104.4 126.8 
7.30  340 -80  55.2  12.4 -18.6  98.9 108.1 133.3 
7.30  340 -75  58.4  13.0 -18.9 104.8 109.2 131.7 
7.30  340 -70  61.1  13.6 -19.1 112.1 110.4 129.9 
7.30  345 -80  54.5  11.5 -19.4 104.6 113.1 138.3 
7.40  160  35 -58.3 -14.4  16.6 285.2 298.7 328.6 
7.40  160  40 -61.0 -14.6  17.4 292.4 299.9 327.1 
7.40  325 -75  61.1  16.8 -15.1  86.1 100.2 127.7 
7.40  330 -75  60.3  15.6 -16.3  92.8 105.2 132.4 
7.40  335 -75  59.4  14.3 -17.6  99.2 110.1 137.2 
7.40  340 -80  55.2  12.4 -18.6  99.4 113.8 143.8 
7.40  340 -75  58.4  13.0 -18.9 105.4 115.0 142.1 
7.40  340 -70  61.1  13.6 -19.1 112.6 116.2 140.3 
7.40  345 -80  54.5  11.5 -19.4 105.1 118.8 148.7 
7.50  160  40 -61.0 -14.6  17.4 292.9 305.5 337.2 
7.50  340 -75  58.4  13.0 -18.9 105.9 120.5 152.2 
7.50  340 -70  61.1  13.6 -19.1 113.1 121.7 150.5 
8.10  160  70 -61.1 -13.6  19.1 353.7 343.8  22.7 
8.10  340 -40  61.0  14.6 -17.4 173.8 160.0 196.0 
8.20  150  75 -60.3 -15.6  16.3  13.9 359.4  39.1 
8.20  155  75 -59.4 -14.3  17.6   7.5 354.5  34.3 
8.20  160  70 -61.1 -13.6  19.1 354.1 348.5  31.2 
8.20  160  75 -58.4 -13.0  18.9   1.3 349.6  29.5 
8.20  340 -40  61.0  14.6 -17.4 174.3 164.7 204.5 
8.30  140  75 -61.8 -18.0  13.8  27.9  13.9  56.9 
8.30  145  75 -61.1 -16.8  15.1  21.0   8.9  52.2 
8.30  150  75 -60.3 -15.6  16.3  14.3   4.0  47.4 
8.30  150  80 -56.4 -14.1  16.8  19.4   5.2  45.9 
8.30  155  75 -59.4 -14.3  17.6   7.9 359.1  42.6 
8.30  155  80 -55.8 -13.2  17.7  13.5   0.3  41.0 
8.30  160  75 -58.4 -13.0  18.9   1.8 354.2  37.8 
8.30  160  80 -55.2 -12.4  18.6   7.7 355.3  36.1 
8.30  165  80 -54.5 -11.5  19.4   2.0 350.4  31.1 
8.30  340 -35  58.3  14.4 -16.6 181.9 170.5 211.3 
8.40  130  75 -62.7 -20.2  11.4  42.5  28.5  74.5 
8.40  130  80 -57.8 -17.1  13.5  44.4  29.8  73.5 
8.40  135  80 -57.6 -16.4  14.3  38.2  24.8  68.6 
8.40  140  80 -57.2 -15.7  15.1  32.0  19.7  63.8 
8.40  145  80 -56.9 -14.9  16.0  25.9  14.7  58.9 
8.40  150  80 -56.4 -14.1  16.8  19.8   9.7  54.0 
8.40  155  80 -55.8 -13.2  17.7  13.9   4.7  49.1 
8.40  335 -35  61.6  18.5 -12.5 183.7 172.1 216.7 
8.40  340 -30  55.1  14.1 -15.6 188.2 176.2 217.9 
8.50  115  80 -57.9 -18.9  11.3  63.7  49.5  95.8 
8.50  335 -30  58.3  18.4 -11.4 190.6 178.1 223.6 

I modified an existing perl script to read these examples, create the 
search file, ephemeris file, and run polesrch.  The results get appended to
an existing file after each time.  

I'm running pole search over a range of diameters between 4.0 and 9.0 km in
0.1 km increments.  Based on the range extents in the images that should be a
safe range; the real diameter is likely in the 6-8 km range.  

Modify one of the _other_ scripts to read in the results

New file: pole.new3.pl

I ran it on all the cases above.  The regions of acceptable pole directions
is almost the same as before although they did shrink a bit.  If we adopt 
normalized residuals = 2.0 (on the bandwidths) as a threshold (on top of the
bandwidth ratio and longitude thresholds already adopted), then the results are:

rotation periods between 6.6 - 7.5 days and 8.1 - 8.5 days are admissible.
Diameters between 5.6 km and 7.0 km are admissible (in the absence of other
information).  I'm surprised that the range of admissible solutions is so large
and I'm a bit surprised that periods of about 7.8 days aren't allowed.  

This excludes Pravec's period.  It doesn't look like we're going to get 
the rotation period (and diameter) without shape modeling.  This also means that
getting the km/Hz conversion isn't going to work as well as I had hoped.

Does it make sense that rotation periods as small as 6.6 days could match
the longitudes so well?  Inspect those results more carefully.  
Double check results for periods between 7.5 and 8.1 days.  Did I miss some?
Were the bandwidth ratios and longitude difference tolerances too high?

DOUBLE CHECK THE PERL SCRIPTS

The rotation tolerances of 15 deg (between Jul 24 and Aug 1) and 40 deg (between
Aug 8 and the average on Jul 24 & Aug 1) are pretty conservative; it would be
appropriate to decrease them to 10 deg and 30 deg.  That won't change the fundamental
results much, though, just the number of admissible spin states and diameters.

We could improve the rotation period constraints by considering the phases on 
dates other than Jul 24, Aug 1, and Aug 8.  For example, the phase on Jul 31 is 
close to the one on Aug. 8.

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

2001 May 8

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

Perl scripts used to constrain the JM8 spin state and their function:
=====================================================================

1. jm8.radpolesearch.pl
-----------------------
Use radpole to scan the entire sky (in 5 deg increments) and a range of rotation periods between 
5.0 and 9.0 days (in 0.1 day increments) to compute subradar latitudes and longitudes for JM8 
observations on July 24, Aug 1, and Aug 8.  Output the results to a text file named: 

results.dat (a huge file) 

2. radpoleparse.pl 
------------------
Parse the results of running radpole over the entire sky and a range of rotation periods.  Get the
computed subradar longitudes and latitudes, select cases when the Jul 24, Aug 1, and Aug 8 longitudes
are similar and when the ratios of the bandwidths between Jul 24/Aug 1 and Aug 1/Aug 8 are within
specified ranges computed using raterr.  The program actually computes the cosines of the latitudes
and takes their ratios.  Spin states that satisfy these criteria are output to a file named:

output.dat

This is the most complicated program of all four Perl scripts used to constrain JM8's spin state
due to all the conditional statements necessary in order to select admissible candidates.  

3. polesearch.new3.pl 
---------------------
Run polesrch over a range of diameters for the spin state candidates identified using 
radpoleparse.pl (one file for each spin state; each file contains labels indicating the diameter).  
The output files contain the measured and computed bandwidths and residuals.  
Output the results to files named: 

jm8.residuals.$period.$lambda.$beta.new 

4. pole.new3.pl    
---------------
Parse the polesrch output files (jm8.residuals.$period.$lambda.$beta.new) and select cases 
in which the residuals/uncertainties from all three bandwidth measurements are less than a 
specified tolerance.  Output the period, lambda, beta, and diameter to a new text file: 

new.minimum.residuals.$tol

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Explore implications of the diameter bounds
-------------------------------------------

H = 15.2 (Pravec et al.)

Deff (km)  pv
--------- ----
7.0       0.03
5.6       0.05

==> JM8 is optically dark, as I've been claiming all along.

These diameter bounds are consistent with the average visible range extents 
in the delay-doppler images.  

The mean 3.5 cm OCxsec = 2.5+/-0.77 km^2 (mean +/- rms dispersion)

Radar albedo (D=5.6 km) = 4*(2.5 km^2)/(pi*5.6*5.6) = 0.10
             (D=7.0 km) = 4*(2.5 km^2)/(pi*7.0*7.0) = 0.065

Clearly JM8 isn't radar bright and it could be radar dark.  So this analysis establishes
preliminary bounds on the radar albedo of 0.065 - 0.10.  As such, JM8 is among the darker
NEAs observed by radar.  These bounds on radar albedo are closer to BFGP and C-type MBAs
than to most NEAs.  NEAs with comparable radar albedos include:

NEAs
====
                          Radar
Rank    Object           albedo +/-     Class                   
----    ------           ------ ---     -----             
12      1620 Geographos   0.12   2.56     S      Equivalent spherical albedo from shape model
13      2062 Aten         0.12   0.94     S      Deff from Cruikshank et al. (1977)
14      1862 Apollo       0.11   1.5      Q      
15      1915 Quetzalcoatl 0.10   0.5      S
16      1580 Betulia      0.09   7.4      C      1989 X-band obs'ns
17      1036 Ganymed      0.064 38.5      S      1988 S-band Obs'ns
18      3757 1982 XB      0.06   0.6      S
19      1566 Icarus       0.04   1.27     S      Deff from Harris (1998)

MBAs
====
23        4 Vesta        0.12   0.04     V
24        7 Iris         0.11   0.03     S
         41 Daphne       0.11   0.04     C
        144 Vibilia      0.11   0.04     C
27        8 Flora        0.10   0.03     S
         27 Euterpe      0.10   0.05     S
29      532 Herculina    0.09   0.05     S
        694 Ekard        0.09   0.04     CP
31       19 Fortuna      0.076  0.027    G
32        2 Pallas       0.075  0.011    B
33       46 Hestia       0.074  0.024    P
34      324 Bamberga     0.066  0.008    CP
35      139 Juewa        0.061  0.025    CP
36        1 Ceres        0.041  0.005    G

- - - - - - - - - - - - - - - - - - 

Steve and I had another discussion over lunch:

1. The similarity of the images on July 24 and August 1 in both longitude and latitude
has been on my mind but I hadn't mentioned it to Steve.  He finally noticed the apparent
latitude similarity.  The question is: why are the images so similar?  Is there enough of
a difference in latitude?

The similarity could be evidence for NPA rotation.  Need to dilate
the Jul 24 image in Doppler and overlay it on the Aug 1 image to see if there was much
latitude motion.  The bandwidth differences suggest the latitude motion was about 30-45 deg.
If we can't convince ourselves that we see that much of a difference, then that's necessary
(but not sufficient) evidence for NPA rotation.  

This raises the prospect that JM8 is an NPA rotator but in a different sense from Toutatis:
with JM8, most of the rotation appears to be about the short axis.  If the rotation is NPA,
then perhaps the apparent spin axis is precessing at a small angle about the angular momentum
vector (and possibly over long time scales).  That would make NPA rotation difficult to 
detect.  If correct, then this is very different NPA rotation from that of Toutatis.  

The first thing I did was to double check my bandwidth estimates.  I got results very similar
to the ones I've been using: 1.72 Hz on Jul 24 and 3.28 Hz on Aug 1.  
When scaled appropriately so that the edges align (done by expanding the July 24 image), it's
clear that there is a modest amound of longitude difference between the images.  The crater-like
features have moved--rapidly blinking between them makes this obvious particularly when I 
remove my glasses

The right way to do this is using reverse grayscale viewgraphs.
That's not necessary--inspection makes the conclusion obvious.  

2. Check the contribution to the apparent rotation produced by sky motion on Jul 24 and Aug 1.
Check both the magnitude and the direction on each day, not the displacement between them.  
Some of this information is output by radpole.  Well, it turns out that we already did this:
The apparent rotation evident from the images is about 50-60 deg/day for a period of about 
1 week.  The maximum sky motion per day was 7 degrees so the rotation caused solely by sky
motion is on the order of 360/7 = 50 days, which is clearly wrong.  Therefore the contribution
to the spin vector by the angular rate is too small to matter.  

3. Start drafting the logic to explain this to ourselves and co-authors.  Run drafts by Steve
and then post them on a website for comments from co-authors.  

4. Check the Perl scripts again to make sure they didn't omit cases that should have been 
included.  At some point, run radpoleparse.pl again with tighter bounds on the ratios.  
One could change the bound on the longitude difference between Aug 8 and the average of
the Jul 24 and Aug 1 images.  

I've read background information the force-free rotation of rigid bodies in four different
books on mechanics.  I have also reviewed work on Toutatis, which I now understand MUCH 
better.  With Toutatis, the spin vector is displaced by a constant angle relative to the long
axis (i.e., Toutatis rotates in long axis mode).  Toutatis rotates about the spin vector
every 5.4 days.  The spin vector rotates about the angular momentum vector (which isn't 
parallel to either a principal axis or to the spin vector) every 7.35 days.  As is illustrated
in the books, this can be visualized as one cone rotating without slipping on the surface of
another cone.  See Barger and Olsson, Classical Mechanics: A Modern Perspective (McGraw-Hill,
1973), pp. 232-239 (especially p. 238).  For a more detailed discussion, see Goldstein.  Toutatis
is in long axis mode so the angle between the spin vector and the angular momentum vector is
relatively large, making NPA rotation easier to detect than with JM8. 

With JM8 our suspicion
is that the rotation is in short axis mode.  That means that the angle between the spin and
angular momentum vectors could be smaller than it is for Toutatis but the angle between
the spin vector and the principal axis would be much larger.  

Symmetric top
-------------
Let alpha = angle between the spin axis and the symmetry (principal) axis
Let theta = angle between the spin axis and the angular momentum vector

tan(alpha) = (I3/I)*tan(theta)

 oblate shape: I3 > I (Earth)
prolate shape: I3 < I (Toutatis...although Toutatis isn't really symmetric)

Where (in this case) I1 = I2 = I (symmetric object)

The rate of precession of the spin vector about the angular momentum vector is
omega = (I3-I/I)*(w), where w = rotation rate.  Depending on the sign, the precession
could be in the same sense as the rotation (oblate spheroid; Earth) 
or in the opposite sense (prolate spheroid; Toutatis).  No, that is incorrect
for Toutatis: the senses of precession and rotation are the same.  Why?

With Toutatis, Ishort/Ilong = 3.19 and Iintermediate/Ilong = 3.01
so Ilong < the other two.  If Toutatis were symmetric, then the precession period
would be less than the rotation period.  But Hudson and Ostro (1995) report that 
the precession period is _longer_ than the rotation period.  Is that because Toutatis
isn't symmetric?  I don't understand this yet; ask Steve.  Hey--if the object is
prolate, then 

, thus making the images appear more regular from day-to-day
if the period of rotation about Wint is substantially shorter than the period of 
precession about L (Wint is the intrinsic spin vector and L is the angular momentum vector).  

Let Wint = the spin vector and Omega = the precession rate
For a symmetric object with I1 = I2 = I (i.e. Earth), 
omega = Wint*(I3 - I)/I so the rotation period and precession periods are linear
functions of each other with the ratios of the moments being the proportionality constant. 

Since JM8 is an NPA rotator, that means our attempts to solve for the rotation period 
and pole direction cannot succeed.  At best, we might get values close to the rotation about
an axis and perhaps a region of space that bounds the precession of the spin vector.  

We want to get the two periods but that will probably require shape modeling.  It would
be sweet if we could provide an estimate of the precession period.  

In any event, our premise that the bandwidth differences on Jul 24 and Aug 1 were due to 
motion of the subradar latitude is incorrect, so the analysis where I tried to pin the
rotation period is invalid.  Is it even worth presenting?  Given that we have compelling
evidence for NPA rotation, that negates the PA rotation stuff.  We could state that we
did extensive PA rotation searches to test for PA rotation

Draft of evidence for NPA rotation
----------------------------------

In images obtained between July 31 and August 8, several prominent features 
are evident that rotate in a regular manner by about 50+/-15 degrees from day to day, 
suggesting that the subradar latitude was close to the apparent equator during that 
interval and that the apparent rotation period Wapp is on the order 
of one week.  Sky motion (Wsky) was less than 7 degrees/day so the contribution to 
apparent rotation has a minimum period of about (360 deg)/(7 deg/day) = 51 days, 
which is much longer than the apparent rotation period in the images.  Therefore the 
contribution by Wsky to the apparent rotation is negligible.

Images obtained on July 24 and August 1 show nearly the same orientation of the 
asteroid but the velocity dispersion on August 1 is about two times larger.  The 
change could be caused by motion of the subradar latitude toward the 
apparent equator; if so, then the factor of two difference in the velocity 
dispersions constrains the subradar latitude on July 24 to exceed about 60 degrees
due to the behavior of the cosine(latitude) function.  
We expanded the Doppler axis of the July 24 image to facilitate comparison of the 
images and found that the prominent crater-like features show subtle differences in 
Doppler frequency that represent modest rotation in apparent longitude.  
These and radar-bright features on both days show differences in 
range relative to the leading edge of less than 2 usec, placing a very conservative
upper bound on the difference in the subradar latitudes of 10 degrees. 
To satisfy the difference in the subradar latitudes and velocity dispersions
the subradar latitude on July 24 must have exceeded about 80 degrees.  
If the subradar latitude on July 24 was at least 80 degrees, then the bandwidth on that
day and the apparent rotation period of about 1 week requires that the diameter
is at least 16 km, which is much larger than is observed.  Consequently, the subradar
latitude on July 24 cannot be 80 degrees and JM8 cannot be a PA rotator.

The change in the bandwidths was not caused by a difference 
in the subradar latitude; instead, it must have been caused by a change in the 
intrinsic spin vector Wint, indicating that JM8 is a non-principal axis rotator.

- - - - - - - - - -  - - -

The regularity of the images during the interval above suggests that the rotation period about the
spin vector is on the order of about one week and that the subradar latitude was close to the 
apparent equator during that interval.  Burns (1971) suggested that the period of precession of Wint 
about
L is much longer than rotation about Wint by up to a factor of ten.  If the object is axisymmetric
then theory predicts that the precession period will be longer than the rotation period.  

Discuss aspects of NPA rotation and allude to Toutatis.  Cannot go far with analysis until the 
shape model
is done (future paper).  Mention the angle between the spin axis and the principal axis about which
the rotation occurs and the angle between them and the angular momentum vector.  The spin vector Wint
precesses about the momentum vector with a period that we don't know yet and may not be able to obtain
until the shape modeling is done.  

Angle between L and Wint could be small; if so, then rotation would be difficult to distinguish
from PA.  Period of precession could be much longer than the rotation period but not necessarily:
with Toutatis the periods are in the ratio of 1.36.  

Show that the subradar latitude isn't at very high values where small differences in
latitude could produce factor of ~2 (1.9) differences in bandwidth.  

cos(60) = 0.5, so the minimum latitude on Jul 24 was about 60 deg if the latitude on Aug 1
was zero.  can any point on the curve be reconciled with the rest of the dataset?  If not, NPA rotator.

Then revise text, post on the web, and contact co-authors.  

Quantify "nearly" the same latitudes using locations of features in the images relative
to the LE.  A quick conservative estimate would be < 10 deg.  
Range resolutions

Jul 24 0.5 us
Aug  1 0.1 us
So range differences of ~0.5 us are consistent given the differences in range res'n.

                                  range diff from LE (us)
feature                      freq  Jul 24  Aug 1
-------                      ----  ------  -----
bright spot "inside" crater   -     7.5     8.0

bright spot inside smaller    
 crater (neg of other one)    -    10.5    10.8

center of top lineament       0     2.5     3.2

center of small dark crater   0     7.5     8.6
near 0 Hz       

So there may have been some latitude rotation--but almost certainly less than about 10 deg.
Features in the images are within about 1 us of each other or ~150 m in range.  If JM8
were a 6 km spheroid then 10 deg of latitude movement could produce a range difference
of 150 m.

Small differences in ranges of features in Jul 24 and Aug 1 images indicate that latitude
motion between those dates was small--less than about 10 degrees.  For there to be less than
10 deg of latitude motion and a factor of 1.9 difference in bandwidth the subradar latitudes
would have to be at least 80 deg on Jul 24 and 70 deg on Aug 1.  In other words, the view 
was close to a pole on both days.  However, other evidence contradicts this:

1. The regular rotation of prominent features in the images between Jul 31 and Aug 9 is 
indicative of subradar latitudes close to the equator, not close to the pole.  

2. There are pole directions consistent with the bandwidths on Jul 24, Aug 1, and Aug 8, 
based on the search I did earlier assuming PA rotation (over a range of
rotation periods), but that search indicates that the maximum subradar latitude on July 24 
is 63 deg, so there's a contradiction.  That search also constrained the subradar latitude
on Aug 1 to be between 12-26 deg.  

3. If the subradar latitude on July 24 was 80 degrees, then that implies that
the diameter of JM8 is: D = B*P/[100*cos(delta)]
                          = (1.7 Hz)*(7 days)*(24 h/day)/[100*cos(80 deg)]
                          = 16.4 km
That is several times larger than the range extent we observe on July 24, so the subradar latitude
cannot be 80 degrees.  Thus, JM8 cannot be a PA rotator.  

----------------------------------------------------------------------------

1. July 31-August 9 images suggest Wapp ~ 1 week (~50 deg/day).

2. Assume principal axis rotation

3. Wapp = Wint + Wsky

4. Sky motion <= 7 deg/day so contribution by Wsky to Wapp is negligible

5. July 24 and August 1 images have very similar longitudes but
   Bjul24/Baug01 = 0.52+/-0.05

6. JM8 moved 50 deg between July 24 and August 1

7. nu = (Wapp x r).e/(lambda/2) (Wapp, r, e are vectors).  Can also be
   written as B = 100 D cos(d)/P

8. Bjul24/Baug1 = cos(djul24)/cos(daug1) = 0.52+/-0.05

9. Bjul24/Baug1 is due to change in cos(d)

10. |daug1| >= 0 deg, so djul24 = acos[(0.52)*cos(daug1)] >= 59 degrees.

11. Features in the July 24 and August 1 images differ by less than
    10 deg of latitude: | djul24 - daug1 | <= 10 deg

12. If djul24 - daug1 <= 10 deg, then djul24 = daug1 + 10  
    but                            cos(djul24) = (0.52)*cos(daug1)
    so                         cos(daug1 + 10) = (0.52)*cos(daug1)
    and cos(daug1)cos(10) - sin(daug1)*sin(10) = (0.52)*cos(daug1)
        sin(10)*sin(daug1) = (cos(10) - 0.52)*cos(daug1)
                tan(daug1) = (cos(10) - 0.52)/sin(10)
                     daug1 = atan(cos(10) - 0.52)/sin(10) = 69.5 deg
          therefore djul24 = 69.5 + 10 = 79.5 deg

13. If djul24 >= 79.5 deg, then D >= B*P/100*cos(djul24)
                                  >= (1.7 Hz)*(~7 d)*(24 h/d)/[100*cos(79.5)]
                                  >= 15.7 km

14. visible range extents (~ 1/2 of true range extents) average 3.6 km, which is
    inconsistent with D >= 15.7 km

15. Bjul24/Baug1 was not caused by change in delta; must be a change
    in Wapp.  So JM8 cannot be a PA rotator

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

2001 May 16

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

I asked Ray and Marty to estimate the subradar longitude and latitude differences
between the July 24 and August 1 images.  They preferred to estimate differences
in pixels; both concluded the differences in Doppler were larger than the differences
in range.  Marty estimated range differences of about 0.5-0.6 us, which are 
consistent with the estimates I got above.  He used two features; I checked more.

- - - - - - - - - - - - - 

Using the measured displacements of features in range relative to the leading edges
on July 24 and August 1, what angles would those displacements correspond to if JM8 
were spherical?

This is a simple trig exercise.  Recall that y = r sin(delta).  dy = y1 - y2 = 0.15 km.
r is about 3.0 - 4.0 km; 3.5 km is my best estimate.  Vary delta1 between 0 - 90 deg
and compute delta 2 and their difference.  It turns out that the difference is less
than 15 deg and exceeds 10 deg only if one of the latitudes is about 81 deg. 
So my estimate of 10 deg is reasonable; in fact, it's very conservative unless we were
very close to the pole, which we couldn't have been due to the diameter contradiction.

- - - - - - - - - - - - - 

I prepared a website and then we sent a modified version of the statements 
above to Mike, Ellen, and Jean-Luc.  They replied within a day and I'm now
drafting a response.  

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

2001 August 23

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

Reduce file VOLT99199-8k with a 256-point FFT to get dfreq = 1.95 Hz
--------------------------------------------------------------------

I had to fix the link to the raw file: all the VOLT file links in /data/ast5/1999JM8/proc/cw/
are wrong.  Deal with the others later if necessary.

reason:/data/ast5/1999JM8/proc/cw < 85 > dofft -d 7.0 -p 168 -f 256 -i VOLT99199-8k.1999JM8 -o 99199-8k.256fft.raw.rdf -x PRDX.OUT.s15
contents of ast_spec control file:
256,
1,
1,
/home/wart/bin/ast_spec_1.25 variables:
DATAIN=VOLT99199-8k.1999JM8
RDFOUT_1=99199-8k.256fft.raw.1_1.rdf
RDFOUT_2=99199-8k.256fft.raw.1_2.rdf
CONTROL=specs_in.dat
Running /home/wart/bin/ast_spec_1.25
/usr/local/bin/jurg2spec -i 99199-8k.256fft.raw.1.rdf -o 99199-8k.256fft.raw.rdf -x PRDX.OUT.s15  -p 168 -d 7.0 
Using .data1 as temporary storage for OC data
Using .data2 as temporary storage for SC data
Total hop states:  2
Total OC spectra:  1576
Total SC spectra:  1576
Processing data...
reason:/data/ast5/1999JM8/proc/cw < 86 > 

Note: I previously reduced the PSD file but it used an 8192 FFT giving 
dfreq =0.061 Hz and only 21 looks.  I used dfreq = 1.95 Hz to estimate
OCxsec and SC/OC for the other dates, so that's why I'm using FFT=256 for
this file.  This file has the most runs of any CW file in the whole
dataset.  

dfreq = 1.95 Hz nearly match-filters the echo in Doppler.  

There are 1576 looks.  Wow.

irun tags are all set = 1.  Block into a file.

Tsys: ch1 = 15.2, ch2 = 16.5  ==> close enough.
gain and trpwr are OK.

I reduced the data.  So far so good.  I change jsnr1, 2 = 60, 70 in order
to completely encompass the echo, which has a large enough Doppler correction
that jsnr1,2 were offset from the echo by about 1 Doppler bin.  

A weighted sum of all the runs has an OC SNR of about 550.  

Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-oc  01:44:05  00:00:00  02:15:37   0.0   3.84e-03   2.46e+00  4.6e-03  2.7
Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.file.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-sc  01:44:05  00:00:00  02:15:37   0.0   4.17e-03   5.20e-01  4.9e-03  2.7 0.211576 0.213629 0.209524

OCxsec = 2.46 km^2
SCxsec = 0.52 km^2
SC/OC  = 0.21+/-0.01

Earlier on the same track (about 4.5 hours earlier) I got OCxsec = 2.96 km^2,
a difference of 19% despite the fact that the asteroid rotated by perhaps 
(4.5 h/24 h/d)*(50 deg/d) = 9 deg.

This is another good illustration of why we don't quote Goldstone cross section
uncertainties of less than 25%.

I plotted the noise histograms: There aren't many points due to the short FFT
and small bandwidth, but the noise is clearly Gaussian.  

Let's take a closer look at OCxsec by blocking into runs.  There are about 160 looks/run
so the noise statistics will still be Gaussian.

change jsnr1,2 again: 60,70

Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-oc  01:44:05  00:00:00  01:45:35   0.0   1.22e-02   1.82e+00  1.5e-02  2.9
  2   1  1999/07/19   2-oc  01:47:24  00:00:00  01:48:58   0.0   1.25e-02   2.69e+00  1.4e-02  2.6
  3   2  1999/07/19   3-oc  01:50:45  00:00:00  01:52:19   0.0   1.22e-02   4.25e+00  1.4e-02  2.6
  4   2  1999/07/19   4-oc  01:54:05  00:00:00  01:55:35   0.0   1.22e-02   2.13e+00  1.4e-02  2.7
  5   3  1999/07/19   5-oc  01:57:26  00:00:00  01:59:00   0.0   1.24e-02   2.12e+00  1.5e-02  2.7
  6   3  1999/07/19   6-oc  02:00:47  00:00:00  02:02:21   0.0   1.21e-02   2.93e+00  1.4e-02  2.6
  7   4  1999/07/19   7-oc  02:04:07  00:00:00  02:05:37   0.0   1.21e-02   2.59e+00  1.5e-02  2.9
  8   4  1999/07/19   8-oc  02:07:27  00:00:00  02:09:01   0.0   1.24e-02   2.49e+00  1.5e-02  2.8
  9   5  1999/07/19   9-oc  02:10:47  00:00:00  02:12:21   0.0   1.21e-02   3.30e+00  1.4e-02  2.6
 10   5  1999/07/19  10-oc  02:14:07  00:00:00  02:15:37   0.0   1.20e-02   2.44e+00  1.5e-02  2.9
Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.runs.rdf

  #  PR  YY/MM/DD RUN-POL  TXSTART   RCSTART     RCEND  PHASE  KMSQ/SDEV    Radar Cross Section Width  RATIO  HIERR LOERR
  1   1  1999/07/19   1-sc  01:44:05  00:00:00  01:45:35   0.0   1.33e-02   5.90e-01  1.6e-02  2.8 0.324156 0.333318 0.315038
  2   1  1999/07/19   2-sc  01:47:24  00:00:00  01:48:58   0.0   1.36e-02   5.69e-01  1.5e-02  2.5 0.211214 0.217045 0.205394
  3   2  1999/07/19   3-sc  01:50:45  00:00:00  01:52:19   0.0   1.32e-02   4.30e-01  1.4e-02  2.1 0.101291 0.10451 0.0980736
  4   2  1999/07/19   4-sc  01:54:05  00:00:00  01:55:35   0.0   1.32e-02   5.15e-01  1.6e-02  3.0 0.241562 0.249383 0.233763
  5   3  1999/07/19   5-sc  01:57:26  00:00:00  01:59:00   0.0   1.35e-02   6.58e-01  1.6e-02  2.7 0.310348 0.318126 0.302599
  6   3  1999/07/19   6-sc  02:00:47  00:00:00  02:02:21   0.0   1.32e-02   5.65e-01  1.6e-02  2.9 0.192957 0.198487 0.187436
  7   4  1999/07/19   7-sc  02:04:07  00:00:00  02:05:37   0.0   1.31e-02   5.29e-01  1.8e-02  3.7 0.204698 0.211781 0.197629
  8   4  1999/07/19   8-sc  02:07:27  00:00:00  02:09:01   0.0   1.34e-02   4.89e-01  1.6e-02  2.6 0.196124 0.202463 0.189799
  9   5  1999/07/19   9-sc  02:10:47  00:00:00  02:12:21   0.0   1.31e-02   6.56e-01  1.7e-02  3.1 0.199146 0.204234 0.194065
 10   5  1999/07/19  10-sc  02:14:07  00:00:00  02:15:37   0.0   1.31e-02   5.31e-01  1.6e-02  3.1 0.217838 0.224726 0.210967

Wow!  The variation is enormous.  Substantial variations in OCxsec are 
obvious in the spectra due to differences in the SNR.  Why do the cross sections
differ by so much?  

So OCxsec varies from 1.82 -> 4.25 km^2, a factor of 2.3, and 
SC/OC varies from 0.10 -> 0.32, a factor of 3.2.  Not good.  Good thing
we did 10 runs...but that raises the disturbing question of the reliability of
OCxsec and SC/OC on the other days, when we usually did only 1-2 runs...
In the future, if time permits, try to do at least 10 cw cycles prior to imaging
and be sure to get enough looks to achieve Gaussian noise statistics.

More fuel for the fire:

Date   file    runs looks OC SNR   B   OCxsec   SC/OC
                                  (Hz) (km^2) (+/-0.01)
________________________________________________________
Jul 18 99199     7   1270   940   1.5   2.96    0.19  
Jul 19 99199-8k 10   1576   540   1.5   2.46    0.21

Note that the SNR also varied considerably between the time when we obtained
99199 and 99199-8k.  

- - - - - - - - - - - - - - - - - - - - 

DIFFERENCE IMAGES
=================

Mike and Ellen suggested we use difference images to show rotation instead of
a sequence.  That's a great suggestion: I hadn't considered it.  It turns out
that Spyglass Transform can do this using the Notebook.  The trick is to get two
images with different names (if they're both Untitled, the default, then the
difference = 0).  An easy way to get the file names is to create a new file, set the
file name and the number of rows and columns, and then paste in the data.  

The Aug 8 difference image is striking: the regions of the most difference are
black and white and they stand out well.  On Aug. 5 the difference is more subtle
due to the shorter time between the images and due to the smaller number of looks,
but it's good enough to make the point that JM8 rotated during the track.

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

2001 August 27

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

COLLAGES, revisited
-------------------

Back in April I didn't document very well how I vignetted the Arecibo images
that I used to create the grand collage (1.02 Hz x 40 us; S-band).  It turns
out that I modified the script used to create the SC/OC images--that is, that
script has the number of columns x rows and the center points.

For reference, here they are:

Date  #cols #rows colcen rowcen      Hz   x  us
----  ----- ----- ------ ------  --------------
Aug 1 105   400   150    1000    0.009807 x 0.1
Aug 2 109   400   169     619    0.009435 x 0.1
Aug 3 115   400   145     415    0.008929 x 0.1
Aug 4 123   400   196     446    0.008335 x 0.1
Aug 5 132   400   135     361    0.007814 x 0.1
Aug 6 140   400   167     350    0.007354 x 0.1
Aug 9 171   400   224     364    0.006025 x 0.1

Ratio images with the Doppler frequency increasing from right to left:

reason:/data/ast5/1999JM8/arecibo/proc/rng/ratio_images < 29 > ls -l *s.tiff
-rw-r--r--   1 lance    staff      41746 Aug 27  2001 jm8.990801.scoc.3.s.tiff
-rw-r--r--   1 lance    staff      41746 Aug 27  2001 jm8.990802.scoc.3.s.tiff
-rw-r--r--   1 lance    staff      41746 Aug 27  2001 jm8.990803.scoc.3.s.tiff
-rw-r--r--   1 lance    staff      41746 Aug 27  2001 jm8.990804.scoc.3.s.tiff
-rw-r--r--   1 lance    staff      41746 Aug 27  2001 jm8.990805.scoc.3.s.tiff
-rw-r--r--   1 lance    staff      41746 Aug 27  2001 jm8.990806.scoc.3.s.tiff
-rw-r--r--   1 lance    staff      41746 Aug 27  2001 jm8.990809.scoc.3.s.tiff

Likewise for files with *gif extensions.

These are ready to assemble into an SC/OC collage.  The range and Doppler extents
match.  

For purely grayscale images, Scott's program pgmstack (on his system) is the fastest
way to create a collage.  For a collage that mixes grayscale and color figures, 
use our tkgraph software (unless Scott has more software than he's made available).

We can create collages using tkgraph.  Don't use the HDS terminals--the 
grayscale images will dither.  Instead, prepare the collage on the console on
rhyme or reason.  tkgraph requires that the figures be gifs and they can be
b & w and/or color.  When the collage is done, write it to a postscript file
and then use alchemy to convert it to a gif.

At their present sizes (200 x 200 pixels), the individual gifs are too large to 
fit onto one or even two vertical pages.  Use XV to shrink them.  If that 
introduces artifacts, then recreate them at smaller sizes using Spyglass Transform
to make tiffs and then alchemy or XV to make gifs.  

The tkgraph template measures 760 pixels down and 588 pixels across in the 
portrait orientation (or vice versa for landscape).  So... there are images from
7 days, so 760/7 = 108.6.  

Another option: Create gifs, ftp them to the Mac down the hall, and use Photoshop
to create the collage.

Or... Is it possible to make a collage using html and then print it to a file?
That might be faster than using tkgraph.

Here's what I did
-----------------

I used XV to change each SC, OC, and SC/OC image to 100 x 100 pixels.  I used
tkgraph to create the collage.  I loaded the Spyglass Transform collage with
Transform, used XV's screen grab feature to grab the color bar, and then imported
it into the SC/OC collage using tkgraph.  I printed the collage to a PostScript
file.  I used alchemy to convert the PostScript file to a gif.  I used XV to
resize the final image so it would fit on the draft manuscript website.  
I also used XV to adjust the size of the color bar so it would fit on the page.
With tkgraph I iterated on the location of the color bar to center it.

Here's the alchemy command line that I used:

alchemy jm8.scoc.collage.ps jm8.scoc.collage.gif -o -g -Zm2 -Zb 2.10i 1.25i 3.08i 1.27i

The last four items specify white space to cut off of the left, bottom,
right, and top in inches.  -Zm2 indicates that it's a color figure. -g specifies
a gif file, and -o overwrites previous copies of the output file.

- - - - - - - - - - 

I adjusted the Aug. 5 difference image using jm8proc on intruder.  I changed the
vignetting to match the extents in the other figures.

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

2002 May 15

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

The manuscript has been accepted by MAPS.  I am modifying the OC image collages to 
include A and G to indicate the observatory.  

It turns out that MAPS can accept only tiffs.  Originally I sent PostScript files.
I used alchemy to convert the files but they didn't look good--they were pixelated.
Ultimately I asked the Photolab for help and Steve Benskin did  a very nice job.
Emails about this are in the JM8 paper notebook.  The key for converting PostScript
to really nice tifs is to use antialiasing.  Steve Benskin pointed that out to me.

Here's what I did for the JM8 difference image figure:

alchemy input.ps output.tif -t -Za4 -Zm1 -Zc -o

where -Za4 sets the antialiasing to its highest (best) value, -Zm1 selects a grayscale
figure, -Zc clips white space around the margins, and -o overwrites "input.tif" if it
already exists in the working directory.  

Today I changed text on the OC collages and I'm trying to convert the new PostScript files
to tifs without using the Photolab (due to their exhorbitant prices).  

Need to experiment with the resolution in DPI.  Previously we used 600 DPI.  

Output an image with 300 dpi:
alchemy input.ps output.tif -t -Za4 -Zm1 -Zc -Zd 300 300 -o

That took just under 3 minutes.  Producing a file with 600 dpi took about 12 minutes.

What we really need is PhotoShop...  

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

2002 May 17

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

New files:

rhyme:/data/ast5/1999JM8/paper/temp < 20 > ls
jm8.oc.collage.aug02_aug09.new.ps    jm8.oc.collage.jul20_aug01.new.ps
jm8.oc.collage.aug02_aug09.new.tif   jm8.oc.collage.jul20_aug01.new.tif

There are some things that have bothered me about the OC image collages:
1. Using tkgraph seems to have sacrificed some resolution.  some details are missing.
2. The stretches on some days make the images too dark and lose detail.
3. The aspect ratios compress the images too much vertically, which also sacrifices
   details.

My original plots were created using Spyglass Transform with echoes saturated at some
percentage of the maximum.  To make this figure I didn't saturate at all used Transform
to make tifs and then XV to adjust the stretches.  However, when I did the stretches all
I didn't use any clipping or saturation, which I had forgotten is easy to do using XV, 
so I'm tinkering with that.  I may reassemble the images.  

Ideally I think these figures would have been better with the vertical dimension increased
by about 50%.  Three parts with 6 panels each would work better than two panels with 8
images each.  

I have modified the stretches of each panel using XV.  That has improved the images
significantly.  Installing the modified gifs into the tkgraph figure is straightforward:
since the tkgraph figure has lines of text, just replace the lines for each previous
figure with the new one.  I copied the old file into a different name and modified 
the new one.

reason:/data/ast5/1999JM8/paper/oc_collage < 55 > cp jm8.oc.collage.aug02_aug09.new.tpl jm8.oc.collage.aug02_aug09.maps.tpl
reason:/data/ast5/1999JM8/paper/oc_collage < 56 > cp jm8.oc.collage.jul20_aug01.new.tpl jm8.oc.collage.jul20_aug01.maps.tpl

The new figures are MUCH better than the old ones, which had low contrast and were too
dark.  The new ones have more contrast, the echoes are brighter, and they're 
downright striking.  

reason:/data/ast5/1999JM8/paper/temp < 73 > alchemy jm8.oc.collage.jul20_aug01.maps.ps jm8.oc.collage.jul20_aug01.maps.tif -t -Za4 -Zm1 -Zc -Zd 600 600 -o
Image Alchemy PS (v1.10) - Copyright (c) 1990-97, Handmade Software, Inc.
Reading PostScript file jm8.oc.collage.jul20_aug01.maps.ps
Writing TIFF file jm8.oc.collage.jul20_aug01.maps.tif (compression type 1)
Interpreting PostScript file /
Saving image........................................                (00:15:27)

rhyme:/data/ast5/1999JM8/paper/temp < 33 > alchemy jm8.oc.collage.aug02_aug09.maps.ps jm8.oc.collage.aug02_aug09.maps.tif -t -Za4 -Zm1 -Zc -Zd 600 600 -o
Image Alchemy PS (v1.10) - Copyright (c) 1990-97, Handmade Software, Inc.
Reading PostScript file jm8.oc.collage.aug02_aug09.maps.ps
Writing TIFF file jm8.oc.collage.aug02_aug09.maps.tif (compression type 1)
Interpreting PostScript file |
Saving image........................................                (00:13:49)

I loaded and printed the tifs using XV.  The resolution of the text is a bit worse than
with the PostScript files but it's good enough.  Steve Benskin at the Photolab is able to
do something that I don't know about to make the figures even better. 

The revised figures still look great.

- - - - - - - - - 

The SC/OC collage in the MAPS pdf file has a blue tint.  Steve likes the blue but I do not
and I want to get rid of it.  I tried to check the tifs we sent to MAPS but I cannot find them.
Those are the files provided to us by the Photo Lab.  I even checked four backup cdroms.  
Where are those files...?   They were very large, so perhaps I thought they were backed up
and deleted them.  Rats... 

Instead, let's go to the PostScript file, use Alchemy to convert it to tif, and
then see how it looks.  If necessary, I can use XV to remove the blue.  

rhyme:/data/ast5/1999JM8/paper/temp < 35 > alchemy jm8.scoc.collage.ps jm8.scoc.collage.tif -t -Za4 -Zm2 -Zc -Zd 600 600 -o
Image Alchemy PS (v1.10) - Copyright (c) 1990-97, Handmade Software, Inc.
Reading PostScript file jm8.scoc.collage.ps
Writing TIFF file jm8.scoc.collage.tif (compression type 1)
Interpreting PostScript file /
Saving image.......................................                 (00:15:21)

rhyme:/data/ast5/1999JM8/paper/temp < 36 > ls -l
total 60176
-rw-r--r--   1 lance    staff    2938705 May 17 15:22 jm8.oc.collage.aug02_aug09.maps.ps
-rw-r--r--   1 lance    staff    3027714 May 17 15:40 jm8.oc.collage.aug02_aug09.maps.tif
-rw-r--r--   1 lance    staff    2938705 May 15 16:05 jm8.oc.collage.aug02_aug09.new.ps
-rw-r--r--   1 lance    staff    2899812 May 15 17:05 jm8.oc.collage.aug02_aug09.new.tif
-rw-r--r--   1 lance    staff    2940126 May 17 15:22 jm8.oc.collage.jul20_aug01.maps.ps
-rw-r--r--   1 lance    staff    3208566 May 17 15:42 jm8.oc.collage.jul20_aug01.maps.tif
-rw-r--r--   1 lance    staff    2940126 May 15 16:05 jm8.oc.collage.jul20_aug01.new.ps
-rw-r--r--   1 lance    staff    2973386 May 15 17:06 jm8.oc.collage.jul20_aug01.new.tif
-rw-r--r--   1 lance    staff    1429986 May 17 17:23 jm8.scoc.collage.ps
-rw-r--r--   1 lance    staff    5413658 May 17 17:47 jm8.scoc.collage.tif

This file is enormous: 5.4 Meg.

jm8.scoc.collage.tif looks fine when viewed with XV: the background is white, not pale blue.
I'm going to send them the new figure electronically just in case.  Just in case the pale blue version
was an artifact of viewing xv at the same time as running Netscape on an 8-bit monitor, I
also checked the tif on rhyme's console w/o Netscape and found that the background is 
white.  

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

Still to do:

1. Apply dofft to some of the data from the first track to get 1.95 Hz resolution.
Use either file 99199B (1000 Hz sampling, 3 runs, and four hops), or file
99199-16k (4000 Hz sampling, 4 hops, 6 runs).  99199-16k would be better because
we should get twice as many looks. 

==> DONE using 99199B-8k.  There is no voltage file for 99199-16k.

2. Check the tags in the Goldstone rdf files: DONE

3. Verify the acunorm normalization in the Goldstone images: IT'S WRONG. ==> I fixed it.

4. Correct the normalization in the Goldstone images using corrected tags: DONE

5. Check for delay drift in the Goldstone images: checked DOY 212 and 213--see evidence
of rotation but no obvious drift.  Ephemeris was good.

6. Tabulate TXoffsets in the images, the delay-Doppler sign convention, and the range/bin 
   for the COM of the OSOD solution for each image. Tabulate the LE locations and center freqs.
	==> DONE

7. Verify that Mike Nolan's rdf conversion worked.  DONE

8. Check the Arecibo image tags (whichever version we end up using). DONE

9. Check for delay drift in the Arecibo images: DONE... hard to tell because
   of jitter in eph_row due to software problems, especially on Aug 1 and 2.
   Any drift is at a level of only a couple of gates.  

10. Write a preliminary draft of a full-length manuscript: say as much as possible
    without the shape modeling.  

11. Look over the Arecibo SC images.  

12. Create ratio images.  To do this, we'll need to
vignette the images to speed calculation and we'll need to clip the levels to 
avoid division by zero.  Prepare one ratio image per day...work with images that
are already weighted sums.  For Toutatis, Keith ignored pixels below certain
thresholds of 5 or 10 sigma.  Keith  mapped other pixels to black.  So the ratios are
taken only on pixels with echo power in both polarizations above a certain threshold.
We have dual polarization images for seven days at Arecibo.  There will still be
chi-square effects due to the small number of looks on some days.  Ratio images 
aren't as important as getting the data to Scott so postpone this until after Steve 
has commented on the draft.  We have OC & SC images from 7 days at Arecibo.

Check for SC/OC bright and dark spots, especially near crater rims.  

13. Experiment with using GIMP and IDL.  See if IDL can plot points on a sphere to
    show sky motion. 

14. Verify that Jean-Luc's rdf conversion worked.  

15. Examine Arecibo CW data.  See if it's worthwhile to estimate radar cross sections
    (probably not) and check SC/OC.

16. Prepare updated Arecibo images and hardcopies

17. Prepare spiffy Arecibo SC/OC images...done

18. Backup the JM8 files onto a CD

19. Put SC, OC, and SC/OC images on a website

20. Tell Scott where SC images area...done

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

Future topics
=============
1.  Correlation between the shape model and spectroscopic features.

2.  Include lightcurves in the inversion and estimation of the spin vector.
    Illumination of the surface during the lightcurves.  Photometric properties.

3.  Combine 3-D shape model with thermal infrared results?

4.  Do the crater sizes on JM8 cross the strength-gravity transition for an object
    of its size?  If so, how does that effect crater morphology?  Asphaug et al.
    (1996) state the large craters on Ida can have asymmetrical shapes due, in part,
    to Ida's non-spherical shape.  So on small bodies, dimensions of relatively 
    large craters may be a function of target gravity, which in turn can be 
    distinctly non-uniform.  That is, as a function of increasing crater size,
    we expect to see a transition of crater morphology from nearly circular in
    map view to more irregular shapes.  ==> Ask Erik.

5.  Radar-bright crater rim: Asphaug et al. (1996) also state that optically 
    bright crater rims on intermediate-sized craters may not be ejecta but instead
    low-velocity surface disturbances.  Presumably local seismic shaking could
    roughen the surface sufficiently to produce the radar bright returns.  Radar
    bright crater rims are worth checking in the SC images and in ratio images.