Summary of chop-nod analysis telecon of Oct. 21, 2009 John, Giles, Lero _____________________________________________________________ Giles' analysis of Serp-FIR1, L483, and L1448-IRS2: We got hours and hours of tau = 0.06 data. Used Sept 2009 RGM supplied Darren in "real time" on the mountain. Used a crude pointing correction, based on linear interpolation of FAZO and FZAO values recorded on excel spreadsheet, rather than painstaking gaussfitting of each file. These two things improved the maps a lot ! (See my recent e-mail to sharpsoftware list serve for current maps). I did some internal consistency checks, though not a full-blown chi2 analysis (see my recent e-mail to sharpsoftware list serve). Serp is very bright and we have good, very reproduceable stuff on Serp (bin-maps not provided but trust me the reproduceability is good). For L483 a two-bin analysis yields terrible results. There was terrible sky noise a few hours after the bin2 data were collected. Could it have started early but gone unnoticed by Nicholas and me? There were some notes of electronic noise during bin1. But could this cause the massive disagreement we are seeing? In any case, we have nothing so far, though more investigation of these data is warranted. For L1448 the two bins seem to agree pretty well, overall. So I am cautiously optimistic that we have believable stuff. Time will tell. Tons of data on Jupiter... tau was 0.1, but data is great. John hopes to get to this in future to investigate possible changes in i.p. due to the new M3 or other factors, but warns his analysis methods are approximate. John wants excel sheet posted ... this is now done, and I also posted Darren's 14,000 ft. rgm-file Serp map suggests NO peak in polarized flux. So ... we need a way to plot polarized flux. John says this is easy in polsharp5 and can be done with about 4 lines of code and the output can be saved to a fits file. Giles suggests adding a few more lines of code to discard data for which the noise on the polarized flux is worse than the median noise times some user-settable factor. I guess this might require writing NaNs to the fits file; hopefully we can figure this out easily. In any case this is a feasible addition to the pipeline that needs to get done. _____________________________________________________________