Hi all,
BICEP2 team meeting today (Tues) will be 2-3pm Pacific, so that Walt can
join:
Phone: 1-866-890-3820 (toll: 1-334-323-7229) Passcode:59702175
group discussion terminates at 1 hour,
any wrap-up discussion < 90 min.
Here is today's agenda:
1) Weekly report from Pole [ Steff ]
- cryo
- bicep.rc / data transfer
- weather: cold and clear
2) Data quality / reduc czar report
This week's report [ Angiola's email ]
status of B2 2012 re-reduction [ Angiola/Randol ]
status of cut definitions / reduc to-do
Next week's czar?
3) General news and plans
- new mailing list working?
- SPIE papers posted...thanks.
4) Analysis pipeline news and plans
see notes below
- pipeline telecon Friday 10 Aug, 4 eastern, 3 central, 1 pacific
5) Other Postings
2012 Aug 1: Generating Synfast Maps with WMAP noise (JET) Updated Aug 3
2012 Aug 6: Sim 1205/1206 (CDS)
2012 Aug 6: Guide to running a simset (CDS)
end of today's agenda.
Notes from yesterday:
-----------------------------------------------------------------------
6 Aug 2012 B2 analysis/pipeline telecon
On the line: John, Randol, Colin, Abby, Chris, Angiola, Jon
B2 reduction (2:00-2:30 eastern) -----------------
status of Angiola's B2 2012 re-reduction
[ Angiola / Randol / Chris to summarize ]
disk space on bicepfs1 and panlfs
- John to ask P Edmon again for quotes [done, quotes for 56 TB more
are coming]
status of thermal stability from Jon:
- Jon is working on season-split (alternate days?) NTD jacks
- will post updated outline of thermal stability project/paper for
tomorrow
Pipeline telecon (2:30-3:30 eastern) ----------------------
WMAP-like noise added to synfast input maps
- Jamie Tolan not on, but briefly discussed his posting (further
discussion Tue/Fri)
- IDL-free, incl. matlab fits binary writer -- awesome.
- noise levels (e.g. 67uK) defined for what area?
- Should we consider more than W-band? Randol says yes, V-band is
what he used.
Abscal: Chris recently changed get_ukpervolt for B2 to 3071, from 3605.
- We need clear abscals for each different B2 epoch!
- Angiola to ask Justus for summary of work done on this, incl. vs.
ell consistency
Plan for closed loop sim/deproj tests:
1. input sim systematics @ best guess B2 level. What are these?
a. relgain--we need closure from per-det abscal or per-pair T/dif
leakage [ Justus / Walt?]
http://bmode.caltech.edu/~spuder/analysis_logbook/analysis/20120117_wmapxco…
b. diff pointing - beams_ab_cmb_bicep2_20100101.csv (per det fits
from CMB, Walt)
c. diff beam size - ?
d. diff ellipticity - ?
2. generate timestreams using 3 sim algorithms:
a1. linear systematic introduced using same template as deproj
a2. best realistic model
a3. best realistic model x2
a1 gives us a check to numerical accuracy (for deprojection on nopol
input) and a clean test of E-to-B only (for deprojection on EnoB input).
a2 or a3 is what we use by default; the ability to increase accuracy
by 2x (e.g. doubling nsides, or the number of beamwidths used for
interpolation) and verify negligible difference in coadded output maps
assures us that sim timestreams are “close enough to reality”.
3. Deproj using linear basis constructed from derivatives.
what is status of gen_templates? [Randol]
width/ellipticity? strategy for interpolation?
Randol's posting here serves as a model:
http://bicep.caltech.edu/~spuder/analysis_logbook/analysis/20120404_diffpoi…
We need to identify a limited set of tags to run this on, and run full
signal (nopol, EnoB, BnoE) and scaled-noise sims.
Each of the signal sims should be generated without systematics, and
with systematics using the 3 sim algorithms.
Each of these simsets should be mapped and processed to aps with and
without deprojection.
We do this first for relgain, diffpoint, and diffwidth separately, and
then in combinations.
Hi Steff,
Thanks very much for your management of this from the Pole end. They
did send out this notification (I hope you are on the SPTR event list)
yesterday, after your email. Great news that we are all caught up.
John
-------- Original Message --------
Subject: SPTR System/Service Event Notification: SPTR System Status Update
Date: Wed, 29 Aug 2012 11:21:27 -0600
From: Seagraves, Sheryl (Contractor) <Sheryl.Seagraves.Contractor(a)usap.gov>
Reply-To: SPTR Notification List <sptr(a)listserv.usap.gov>
To: SPTR Notification List <sptr(a)listserv.usap.gov>
Hello,
ASC IT staff and science support personnel have successfully designed
and fabricated a replacement section of Ku-Band waveguide for the SPTR2
system. Yesterday the repair team installed the new section and ran
three test passes, transmitting data as expected.
Full Ku-band services will be restored with the next scheduled pass, and
additional passes will be added to manage data backlog. The system will
be closely monitored to track performance. When performance levels are
confirmed, an estimate for the time to reduce data backlog will be
determined and forwarded to the user community.
Many thanks to the dedicated personnel on station and in the US who
worked to complete these repairs and return the system to operations.
Thank you,
The SPTR Operations Team
_______________________________________________
To subscribe to this mailing list send an e-mail
message, from the email account you wish to
subscribe, to sptr-subscribe(a)listserv.usap.gov.
To unsubscribe from this mailing list send an
e-mail message, from the email account you wish to
unsubscribe, to sptr-unsubscribe(a)listserv.usap.gov.
Hi,
Although we haven't received any notification, data seems to be going
out again. Currently data starting 8/27 is queued. I'll keep putting on
some extra files until we have caught up.
Cheers,
Steffen
On 2012-08-29 11:22, Steffen Richter (BICEP2) wrote:
> Hi,
>
> On 2012-08-29 01:32, John Kovac wrote:
>>
>> Randol/all,
>>
>> I expect return of the SPTR link will happen very soon. I have been
>> in touch with Steff, John Carlstrom, and Derek on this and Derek has
>> machined a replacement waveguide part. Last I heard (> 36h ago,
>> before I left China) a test of the system was imminent.
>>
>> Steff: I suspect there may be a large enough data backlog that it
>> will take multiple passes to catch up. Probably best to start with
>> the most recent data, if possible.
> Yes, that is the plan. I have been rotating data in and out of the
> SPTR server in anticipation of a fix. When I spoke to Jeremy the other
> day, he indicated that today might be the day for a test at least.
>
>
> Cheers,
> Steffen
>
>>
>> cheers,
>> John
>>
>>
>>
>>
>> On 8/28/12 9:18 AM, Randol Aikin wrote:
>>> Hi Steff,
>>>
>>> If the return of the Ku band isn't imminent, as you said in an
>>> earlier email, we should probably work on getting data quality checks
>>> happening at pole. Let me know how you would like to proceed - I
>>> don't think there is much harm in waiting a few more days to see if
>>> the data transfer is restored. If it's going to be much more than
>>> that, I can help you get the reduc plots working at pole.
>>>
>>> Thanks much, Randol
>>>
>>>
>>> On Aug 28, 2012, at 8:22 AM, Steffen Richter (BICEP2) wrote:
>>>
>>>> Hi All,
>>>>
>>>> Observing: ---------- 120827 09:12:25 - still running *
>>>> 9_CMB_36b_dk113_015.sc
>>>>
>>>> 120827 09:06:30 - 120827 09:07:55 * mce_autotune.sch * MASD
>>>> restart, DSP driver reload & mce_reset_clean, GCP restart after
>>>> running schedule.
>>>>
>>>> 120827 04:39:37 - 120827 07:36:57 *
>>>> starpoint_pole_bicep_winter.sch * Tilts: az 0° 180° x -8.904
>>>> -9.377 y 9.646 10.448
>>>>
>>>> 120827 03:44:20 - 120827 03:49:56 * do_cycle.sch * dk=0 mark OK *
>>>> cleaned GS, boot, UFB * Membran 0.10/0.40
>>>>
>>>> 120827 03:25:24 - 120827 03:31:03 * do_cycle.sch * Fridge cycle
>>>> process died
>>>>
>>>> 120824 09:21:03 - 120827 03:25:24 * 9_CMB_36b_dk068_015.sch * MCE
>>>> error @ 20120825 06:16:12:
>>>>
>>>> /home/bicep/gcp/control/../masd/specific/scripts/mce_fast_pipe:
>>>> line 74: 50000000 / Reply does not match command. / 60 : syntax
>>>> error: invalid arithmetic operator (error token is ". / 60 ")
>>>> /home/bicep/gcp/control/../masd/specific/scripts/mce_fast_pipe:
>>>> line 77: / 140 : syntax error: operand expected (error token is "/
>>>> 140 ")
>>>>
>>>> * Power outage starting @ 120824 16:13:31, lasting 10-15 minutes.
>>>> Kept running on UPS.
>>>>
>>>> 120824 09:18:30 - 120824 09:19:55 * mce_autotune.sch * ran again by
>>>> accident * MASD restart, DSP driver reload & mce_reset_clean after
>>>> running schedule.
>>>>
>>>> 120824 09:15:37 - 120824 09:17:01 * mce_autotune.sch * MASD
>>>> restart, DSP driver reload & mce_reset_clean, GCP restart after
>>>> running schedule.
>>>>
>>>> 120824 03:52:21 - 120824 03:57:59 * do_cycle.sch * Tilts: az 0°
>>>> 180° x -8.904 -9.432 y 9.778 10.338 * dk=0 mark OK *
>>>> cleaned GS,
>>>> boot, UFB * Membran 0.10/0.40
>>>>
>>>> 120821 13:59:12 - 120824 03:37:13 * 9_CMB_36a_dk293_015b.sch
>>>>
>>>> 120821 09:36:34 - 120821 13:57:14 * 9_CMB_36a_dk293_015.sch * Page
>>>> for MCE error @ 20120821 13:50:46. Error from MCE command @ 2012
>>>> 13:47:44:
>>>>
>>>> /usr/mce/mce_script//script/mce_run: line 133: 31949 Segmentation
>>>> fault mce_cmd -q -o / $lock_opts -X
>>>> "acq_config${acq_config_suffix} $filename rc$rc" -X "acq_go
>>>> $numpts"
>>>>
>>>> * Aborted schedule * stop MASD, mce_reset_clean, reload dsp driver,
>>>> mce_reset_clean, start MASD
>>>>
>>>>
>>>> Telescope: ---------- - One pointing schedule - Temperature
>>>> problems in DSL sorted. Load leveler room fan hasn't come on again
>>>> - 10-15 minute power outage. Didn't affect us other than crane
>>>> heater turning off and cryo monitoring computer requiring twiddling
>>>> with the serial ports - One non-fatal and on fatal MCE error that
>>>> required mce software reset and a schedule restart, thus losing one
>>>> scan set - One fridge cycle process died
>>>>
>>>> Weather -------- - Mixed, but mostly fine
>>>>
>>>> Cryogenics: -----------
>>>>
>>>> * Did the last complete transfer out of Simon. Considering the
>>>> amount of LHe we have I suggest not doing a partial transfer but to
>>>> fill from Theo instead and boil off the remaining liquid in Simon
>>>> and compress the gas into the half rack. Any comments on that
>>>> welcome.
>>>>
>>>> * Continue to not pressurize the Wessingtons w/ GHe.
>>>>
>>>> * Tracking spreadsheet at
>>>> http://bicep.rc.fas.harvard.edu/bicep2/south_pole_helium_usage/Summer_2011_…
>>>>
>>>>
>>>>
>>>>
>> * Kathleen's Cryo Sitrep:
>>>>
>>>> LHe: • Approximately5400 liters of useable LHe remain in the
>>>> Wessington dewars. • Approximately 250 liters of LHe were delivered
>>>> to BICEP2. • Based on a historical consumption rate of 35.7
>>>> liters/day, LHe supplies are expected to be exhausted by January
>>>> 2013
>>>>
>>>> GHe: • Out of 16 storage tanks for gaseous helium: 6 tanks are at
>>>> 17.2 MPa (2500 psi), one tank is at 13.8 MPa (2000 psi), two tanks
>>>> are at 10.3 MPa (1500 psi), one tanks is at 7.6 MPa (1100 psi), one
>>>> tank is at 3.4 MPa (500psi), two tanks are at 1.4 MPa (200 psi),
>>>> two tanks are at 1.0 MPa (150 psi), and one tank is at 0 MPa (0
>>>> psi). • Vent GHe from the LHe transfer was compressed into the
>>>> storage tanks.
>>>>
>>>>
>>>> LN2: • The liquid nitrogen plant tuned off all week • Approximately
>>>> 250 liters of LN2 are currently stockpiled on station.
>>>>
>>>>
>>>> Analysis/software/computers: ---------------------------- - Updated
>>>> firewall and cryo monitoring computer for upcoming pen test. -
>>>> TDRSS Ku band still out, so no data. Waveguide has been machined by
>>>> Derek, just waiting for approval from Denver, possibly tomorrow.
>>>>
>>>> Cheers, Steffen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Hi All,
We will have a BICEP2 meeting today at 2pm Pacific.
Phone: 1-866-890-3820 (toll: 1-334-323-7229) Passcode:59702175
group discussion terminates at 1 hour,
Agenda:
1) Weekly report from Pole [ Steff ]
2) Data quality / reduc czar report
This week's report [ Angiola's email ]
status of B2 2012 re-reduction [ Angiola/Randol ]
Next week's czar?
3) General analysis news and plans
4) Logbook postings
2012 Aug 17: Radial Basis Function Interpolation and Interpolation Precision (STF)
Hi All,
Here are reduc notes for the week. Examining scansets 20120813F05
through 20120818F05.
Weather has been good, marginal during some scansets.
Data reduction: re-reduction of 2010+2011 data still
ongoing - so far reprocessed data from
Jan 2010 through part of July 2011.
Additional details below -
Angiola
Weather :
-------------------------
20120815B05_dk113 - marginal wx first half scanset (scanset cut)
20120818C03_dk248 - marginal leading elnod (scanset not cut)
20120818C04_dk248 - marginal wx (scanset cut)
20120818C05_dk248 - marginal wx (scanset not cut)
20120818C07_dk248 - marginal wx/leading elnod (scanset not cut)
20120818E09_dk248 - marginal wx 2nd half scanset (scanset cut)
20120818E10_dk248 - marginal wx during scan (scanset cut)
20120818F02_dk248 - marginal wx 2nd half scanset (scanset cut)
20120818F03_dk248 - marginal wx first half scanset (scanset cut)
Other (scansets cut):
-------------------------
20120815I07_dk113 - (round2, stationarity_ab cut)
20120818E02_dk248 -(round2, stationarity_ab cut)
20120818E03_dk248 -(round2, stationarity_ab cut)
Individual channel notes :
---------------------
20120813F06_dk068 - bad channel (step) in leading elnod
20120813G05_dk068 - bad channel (step) in trailing elnod
20120813H10_dk068 - bad channel (step) in trailing elnod
20120813I01_dk068 - bad channels (steps) in trailing elnod
20120813I04_dk068 - bad channel (step) in trailing elnod
20120813I06_dk068 - bad channels (steps) in trailing elnod/elnod diff
20120815B04_dk113 - bad channels (steps) in trailing elnod
20120815C02_dk113 - bad channel (step) in leading elnod
20120815C09_dk113 - bad channel (step) in leading elnod
20120815D02_dk113 - marginal channel in pair diff
20120815D03_dk113 - marginal channel in pair diff
20120815E09_dk113 - bad channel (step) in leading elnod
20120815F02_dk113 - bad channel (step) in leading elnod
20120815F07_dk113 - bad channel (step) in leading elnod
20120815F10_dk113 - bad channel (step) in leading elnod
20120815G03_dk113 - bad channel (step) in leading elnod
20120815H07_dk113 - bad channel (step) in leading elnod
20120818B09_dk248 - bad channel (step) in trailing elnod
20120818C08_dk248 - bad channel (step) in leading elnod
20120818C09_dk248 - bad channels (steps) in leading elnod/elnod diff
20120818D04_dk248 - bad channel (step) in leading elnod
Hi All,
Here are reduc notes for the week. Examining scansets 20120803I04
through 20120812F04.
Weather has been good, marginal during some scansets.
Syncbox problems (see Steff's weekly report) affect scansets
20120812E01 through 20120812F04.
Data reduction: started re-reduction of 2010+2011 data
(ongoing, reprocessed ~ 7 months of 2010 data so far)
Online cut plots : updated to include the new 'round2' cut parameters
('num_fj', 'num_destep', 'max_fj_gap',
'rtes_frac', 'rnorm', 'pjoule')
http://bicep.rc.fas.harvard.edu/bicep2/reduc_plotcuts/
Additional details below -
Angiola
Marginal weather :
-------------------------
20120809C08_dk293 - marginal wx (scanset cut)
20120809C09_dk293 - bad leading elnods (scanset not cut)
20120809D07_dk293 - marginal wx (scanset cut)
20120809I06_dk293 - bad wx (scanset cut)
20120809I07_dk293 - marginal leading elnods (scanset not cut)
20120809I10_dk293 - marginal wx/trailing elnods (scanset not cut)
20120812B09_dk068 - marginal wx? (scanset cut)
Syncbox problems (scansets cut) :
---------------------------
20120812E01_dk068 through 20120812F04_dk068
Missing scanset:
----------------
20120812F04_dk068 - aborted schedule
Other (scansets cut):
-------------------------
20120806E02_dk248 - (round2, stationarity_ab cut)
20120806G03_dk248 - (round2, stationarity_ab cut)
20120806I08_dk248 - (round2, stationarity_ab cut)
20120809H05_dk293 - (round2, stationarity_ab)
20120812C05_dk068 - (round2)
Individual channel notes :
---------------------
20120803I07_dk113 - bad channel (step) in leading/trailing elnod
20120806B02_dk248 - bad channels (steps) in leading elnod/elnod diff
20120806B07_dk248 - bad channels (steps) in leading elnod/elnod diff
20120806B08_dk248 - bad channels (steps) in leading elnod diff/elnod
20120806D02_dk248 - marginal channel in pair diff
20120806D03_dk248 - marginal channel in pair diff
20120806F08_dk248 - bad channel (step) in leading elnod
20120806F09_dk248 - bad channel (step) in trailing elnod diff
20120806G01_dk248 - bad channel (step) in leading elnod
20120806H03_dk248 - bad channels (steps) in leading elnod
20120809D01_dk293 - marginal channel in pair diff
20120809D02_dk293 - marginal channel in pair diff
20120809E03_dk293 - bad channel (step) in leading elnod
20120809F10_dk293 - bad channel (step) in trailing elnod
20120809G04_dk293 - bad channel (step) in trailing elnod
20120809H04_dk293 - bad channel (step) in trailing elnod
20120809H10_dk293 - bad channel (step) in trailing elnod
20120812B01_dk068 - bad channel (step) in leading elnod
20120812C01_dk068 - bad channels (steps) in leading elnod
20120812D06_dk068 - bad channels (steps) in leading elnod
Sarah and Walt, FYI the below email on Skynet communication. Upper
limits in uK would be valuable.
The Jan B2 tests (I've reattached the report) imply we should expect
pickup in a handful of channels at the ~100 uK level, and in median
channels at 10 uK, assuming 30 dB suppression due to being 40 deg out on
the Skynet sidelobe.
Sarah mentioned on the telecon today that 500 uK upper limit, though she
didn't say whether this was for every individual channel. That would at
least be consistent with expectations.
One could presumably take an average of RGL's to see if we can place an
upper limit on the mean level of pickup...
John
-------- Original Message --------
Subject: Re: skynet test [ping]
Date: Thu, 02 Aug 2012 16:05:13 -0400
From: John Kovac <jmkovac(a)cfa.harvard.edu>
To: Smith, Patrick D. <pdsmith(a)nsf.gov>
CC: John Ruhl <ruhl(a)case.edu>, John Carlstrom <jc(a)kicp.uchicago.edu>,
"Papitashvili, Vladimir O." <vpapita(a)nsf.gov>
Thank you Pat--we are also very interested in the SPTR-2 transmit times
John Ruhl requested.
In our own BICEP2 and Keck data from the brief NATO-4B 3.8 Hz test, we
are still working on determining whether features near 3.8 Hz which we
see in a subset of detectors are unique to the period of Skynet
transmission. In either case we will quantify the amplitude (or upper
limit) for 3.8 Hz in science data units (uK), and will compare to
expectations based on the January BICEP2 pickup test, extrapolated to 40
deg AZ offset--this should give us two ways to estimate contamination
levels and ultimately answer your question "how many dB suppression is
needed".
cheers,
John
On 8/2/12 2:46 PM, Smith, Patrick D. wrote:
> John:
>
> First things first. I just sent out the data call email, with you and
> the others on this email on the cc list. Once we get that out of the
> way, we can then think about coordinating a test.
>
> We've been having equipment problems with the SPTR-2 RF chain, so I'm
> not sure what our relative risks would be to perturb a currently working
> configuration - not wanting to put at risk out operational service.
> Also, I'm not sure what the technical considerations will be to
> replicate at 3.8 Hz modulation (I'm assuming you are talking about a
> pulsed amplitude modulation - 50% duty cycle square-wave of an
> un-modulated RF carrier, on/off, at 3.8 Hz). We'd have to see how much
> of the system configuration would have to be tinkered with to do this,
> and then do a risk assessment to make sure we don't do something that
> could put a return to normal ops at risk.
>
> The default carrier modulation routinely used is a quadrature phase
> shift keyed (QPSK) waveform at a 123 MHz data rate with Rate 1/2 forward
> error correction (FEC). Here is an example calculation for the
> transmitted carrier:
>
> *Variable Name*
>
>
>
> *Variable*
>
>
>
> *Value*
>
>
>
> *Units*
>
> Data Rate
>
>
>
> DR
>
>
>
> 123
>
>
>
> MHz
>
> Modulation Factor
>
>
>
> m
>
>
>
> 2
>
>
>
> QPSK
>
> Viterbi FEC Rate
>
>
>
> CRv
>
>
>
> 0.5
>
>
>
> Rate 1/2
>
> ReedSolomon FEC Rate
>
>
>
> CRrs
>
>
>
> 0.921568627
>
>
>
> Rate 188/204
>
>
>
> *Symbol Rate*
>
>
>
> *SR*
>
>
>
> *133.4680851*
>
>
>
> **
>
> SR = DR / (m * CRv * CRrs)
>
> QPSK has a sin(x)/x type of power spectra.
>
> Pat
>
> -----Original Message-----
> From: John Ruhl [mailto:ruhl@case.edu]
> Sent: Thursday, August 02, 2012 1:48 PM
> To: Smith, Patrick D.
> Cc: John Kovac; John Carlstrom; Papitashvili, Vladimir O.
> Subject: Re: skynet test [ping]
>
> Pat -
>
> I'm not sure if I'm understanding you correctly… obviously when
> talking to the satellite you have to use their spec'd modulation. Can
> you do a TDRSS broadcast test (100% amplitude modulated at something
> like 3.8Hz), not during a satellite window? You could be pointed a few
> degrees away from the satellite, even, or do it when the satellite is
> below the horizon.
>
> thanks,
>
> John
>
> CWRU office: (216)368-4049
>
> On Aug 2, 2012, at 1:43 PM, "Smith, Patrick D." <pdsmith(a)nsf.gov
> <mailto:pdsmith@nsf.gov>> wrote:
>
> > John:
>
> >
>
> > I'll see what I can do.
>
> >
>
> > Re the modulation, due to operational concerns, we're stuck with what
> the system has to operate with. I believe that we are using Rate 1/2
> FEC QPSK modulation. We have to be compatible with NASA White Sands
> requirements. The data encoding is using a CCSDS standard, so I could
> ask if a spec on this could also be provided to you.
>
> >
>
> > Pat
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: John Ruhl [mailto:ruhl@case.edu]
>
> > Sent: Thursday, August 02, 2012 1:38 PM
>
> > To: John Ruhl
>
> > Cc: Smith, Patrick D.; John Kovac; John Carlstrom; Papitashvili,
> Vladimir O.
>
> > Subject: Re: skynet test [ping]
>
> >
>
> > Pat -
>
> >
>
> > By the way, it would be great to have a list of transmission times
> in both pointings, so we can compare.
>
> >
>
> > thanks,
>
> > John
>
> >
>
> > CWRU office: (216)368-4049
>
> >
>
> >
>
> > On Aug 2, 2012, at 1:33 PM, John Ruhl <ruhl(a)case.edu
> <mailto:ruhl@case.edu>> wrote:
>
> >
>
> >> Pat -
>
> >> I would love to get your list of SPTR-2 transmission times; for the
> last couple/few weeks would be a good start. We are seeing some
> interesting phenomenology in some of our detectors, but I don't know
> whether RF pickup is a good model for that. It would also be helpful to
> know what the broadcast signal looks like, ie carrier frequency and
> modulation type.
>
> >>
>
> >> The skynet transmission was 100% modulated, so much easier to look
> for. Would it be possible to do a similar test with SPTR-2?
>
> >>
>
> >> We are working hard to get the answer to the question that you
> asked, regarding suppression. We'll have much better information on
> that soon.
>
> >>
>
> >> thanks,
>
> >> -John
>
> >>
>
> >>
>
> >>
>
> >> CWRU office: (216)368-4049
>
> >>
>
> >>
>
> >> On Aug 2, 2012, at 12:43 PM, "Smith, Patrick D." <pdsmith(a)nsf.gov
> <mailto:pdsmith@nsf.gov>> wrote:
>
> >>
>
> >>> Thanks John, I appreciate the information. Based on this
> advanced-look information, the answer to my "how many dB of suppression
> do we have to do?" question is critical.
>
> >>>
>
> >>> Do you mind if I share your information below with the Skynet team?
>
> >>>
>
> >>> Also, and I shudder to bring this up but need to for your benefit
> --- Have you seen any artifacts in your data that might correlate to our
> SPTR-2 earth station transmissions? This would be a harder phenomenon
> to detect, as most of our SPTR-2 TDRS operations are with the satellite
> located at 169.5 deg East, which puts Dark Sector clearly on the SPTR-2
> antenna backlobe. However, on occasion, we use the TDRS satellite
> located at 49 deg W, which means we have about a 48 deg angular
> separation from Mapo from the SPTR-2 boresight. SPTR-2 uses a slightly
> larger antenna (3.5 m v. 2.4 for Skynet), implying a narrower beam
> pattern and better sidelobe supression, but one of the operating
> frequencies (S-Band) is lower than Skynet (X-Band), which would imply a
> broadening of the beam pattern. The uplink power levels will also be
> different, but if you say you are seeing a high S/N in the NATO-4B
> uplink bogey, I suspect that 3 dB or so in difference in SPTR-2 v.
> Skynet terminal uplink power would not matter. I raise this because
> you may be getting data contamination and not even know it. We can
> probably get you a historical schedule of our SPTR-2 transmissions
> (scheduled, at least) for any operations to the satellite at 49W. Are
> you interested, and if so, how many days back would you want to go,
> starting from today's date?
>
> >>>
>
> >>> Pat
>
> >>>
>
> >>>
>
> >>> -----Original Message-----
>
> >>> From: John Ruhl [mailto:ruhl@case.edu]
>
> >>> Sent: Wednesday, August 01, 2012 7:29 PM
>
> >>> To: Smith, Patrick D.
>
> >>> Cc: John Kovac; John Carlstrom; Papitashvili, Vladimir O.
>
> >>> Subject: Re: skynet test [ping]
>
> >>>
>
> >>>
>
> >>> Pat -
>
> >>>
>
> >>> What I can report right now is that we see the 3.8Hz modulated
> skynet transmission with high S/N in our 150GHz detectors. We are now
> working to understand both what the likely mechanism for the pickup is,
> and how this translates to science impact.
>
> >>>
>
> >>> We still have some fairly straightforward analyses to do that
> should help our understanding, but after that is done I think we'll be
> ready to have a discussion with you about paths forward.
>
> >>>
>
> >>> thanks,
>
> >>> John
>
> >>>
>
> >>> CWRU office: (216)368-4049
>
> >>>
>
> >>>
>
> >>> On Aug 1, 2012, at 4:40 PM, Smith, Patrick D. wrote:
>
> >>>
>
> >>>> John R. and John K.:
>
> >>>> This is your semi-weekly ping. How are things going?
>
> >>>>
>
> >>>> The Skynet team has just gotten word from Intelsat that we can
> make a long term swap in service from Skynet-4C to NATO-4B, which should
> give us the time to work the earth terminal relocation issue and
> establish a new (hopefully long term) location that does not look over
> Dark Sector. In the interim, we can continue service from the current
> earth station location looking at NATO-4B at 34E. We are also going to
> explore testing at 3 Mb/s, to see if we can operate at double the link
> rate we had spec'ed.
>
> >>>>
>
> >>>> The last "i" to dot for this provisional working CONOPS is the
> outcome of your test data analysis.
>
> >>>>
>
> >>>> Eagerly awaiting the outcome.
>
> >>>>
>
> >>>> Pat
>
> >>>>
>
> >>>> -----Original Message-----
>
> >>>> From: Smith, Patrick D.
>
> >>>> Sent: Friday, July 27, 2012 8:42 AM
>
> >>>> To: John Ruhl
>
> >>>> Cc: John Kovac; John Carlstrom; Papitashvili, Vladimir O.; Smith,
> Patrick D.
>
> >>>> Subject: RE: skynet test
>
> >>>>
>
> >>>> Thanks John.
>
> >>>>
>
> >>>> The team is eagerly awaiting your results.
>
> >>>>
>
> >>>> At issue for the team are the following:
>
> >>>>
>
> >>>> 1. Ability to go into operational communications on NATO-4B during
> the remainder of this year and continue until ~ Feb 2014, by which time
> we hope to have relocated the earth terminal to a better location with
> less chance of interference. Going operational will help us realize a
> return on investment of the ~ $650K spent on the space
> segment/international backhaul for the year.
>
> >>>>
>
> >>>> 2. Decision on the site location to move the earth terminal. We
> should be doing pad/site work this coming austral summer in preparation
> for an installation in the 2013/2014 season, with commissioning by end
> of Jan 2014. We still don't know if our proposed "Site 8" will work.
>
> >>>>
>
> >>>> 3. If Site 8 does not work in regards to interference, then our
> option is to try to push it even further north so that Dark Sector is
> behind (i.e., on the backlobe), and work on redesigning the antenna to
> reduce backlobe energy spillage (e.g., tapered feed illumination,
> reflector skirt, etc.). To move further to the north will invoke a
> feasibility assessment to see if additional 4160 VAC power taps can be
> created in the station to allow us the transmission power voltage we
> need to extend the distance. As it is, the station cannot support any
> additional 4160 power feeds, requiring an engineering effort to
> address. This all adds cost, complexity, and time to the schedule. I
> have to get all of this scoped and briefed to my management to see if
> they are willing to fund it.
>
> >>>>
>
> >>>> 4. If we can't make a variant of Site 8 work at all, our only
> recourse is our "Site 10", which is in the backlobe of SuperDARN's HF
> radar emissions, and we aren't sure what the EMI effects would be. We
> would have to get busy with some engineering to try to
> estimate/anticipate the interference issues to see if it is worth the
> risk to move to Site 10.
>
> >>>>
>
> >>>> For reference, updated site selection drawings are attached so you
> can refresh your understanding of where these two locations are.
>
> >>>>
>
> >>>> Therefore, the results of your data analysis of the NATO-4B test,
> plus a comment on my question re "how many dB of suppression do we need
> to supply to push us into your noise", are in the critical path for
> resolving the long term deployment of the earth station, and time is
> getting short to converge on a final site to enable initial site prep
> work to occur this coming season.
>
> >>>>
>
> >>>> No pressure, or anything.... :-)
>
> >>>>
>
> >>>> Cheers,
>
> >>>> Pat
>
> >>>>
>
> >>>>
>
> >>>> -----Original Message-----
>
> >>>> From: John Ruhl [mailto:ruhl@case.edu]
>
> >>>> Sent: Friday, July 27, 2012 6:27 AM
>
> >>>> To: Smith, Patrick D.
>
> >>>> Cc: John Kovac; John Carlstrom; Papitashvili, Vladimir O.
>
> >>>> Subject: Re: skynet test
>
> >>>>
>
> >>>> Pat -
>
> >>>>
>
> >>>> Sorry to not have gotten back to you before your meeting.
>
> >>>> We're seeing some "interesting" behavior, still sorting it out but
> making good progress. Reliable results soon, I hope!
>
> >>>>
>
> >>>> -John
>
> >>>>
>
> >>>> CWRU office: (216)368-4049
>
> >>>>
>
> >>>>
>
> >>>> On Jul 25, 2012, at 9:10 AM, Smith, Patrick D. wrote:
>
> >>>>
>
> >>>>> John^2:
>
> >>>>>
>
> >>>>> How is the data analysis coming? I have a Skynet project team
> meeting coming up tomorrow, and I am sure to be pinged on status. I'd
> like to give the team an update on when we can expect to get briefed on
> the results of the latest test re NATO-4B.
>
> >>>>>
>
> >>>>> FYI, in case you haven't heard yet, the USAP Blue Ribbon Panel
> Report has been publically released. There is a chapter on
> Communications and IT, and there is a significant reference to South
> Pole broadband communications and the need for improvement.
>
> >>>>> See:
>
> >>>>> http://www.nsf.gov/od/opp/usap_special_review/usap_brp/rpt/antarct
>
> >>>>> i
>
> >>>>> ca
>
> >>>>> _
>
> >>>>> 07232012.pdf (pp. 129-139)
>
> >>>>>
>
> >>>>> Rgds,
>
> >>>>> Pat
>
> >>>>>
>
> >>>>>
>
> >>>>> -----Original Message-----
>
> >>>>> From: John Kovac [mailto:jmkovac@cfa.harvard.edu]
>
> >>>>> Sent: Wednesday, July 18, 2012 7:02 AM
>
> >>>>> To: John Ruhl
>
> >>>>> Cc: Smith, Patrick D.; John Carlstrom; Papitashvili, Vladimir O.
>
> >>>>> Subject: Re: skynet test
>
> >>>>>
>
> >>>>>
>
> >>>>> Hi Pat,
>
> >>>>>
>
> >>>>> I second that--these are excellent questions and we're working on
> the answers. Our analysis team is hard at it this week--we'll be
> comparing our findings with John Ruhl and discussing them asap.
>
> >>>>>
>
> >>>>> John
>
> >>>>>
>
> >>>>>
>
> >>>>> On 7/17/12 11:19 PM, John Ruhl wrote:
>
> >>>>>> Pat -
>
> >>>>>>
>
> >>>>>> All good questions. Until we get our analysis straight I don't
> think we can answer any of them, but we'll get there!
>
> >>>>>>
>
> >>>>>> As soon as we and the bicep/spud crew have final numbers from
> this test, we'll talk.
>
> >>>>>>
>
> >>>>>> thanks,
>
> >>>>>> John
>
> >>>>>>
>
> >>>>>> CWRU office: (216)368-4049
>
> >>>>>>
>
> >>>>>>
>
> >>>>>> On Jul 17, 2012, at 7:40 PM, Smith, Patrick D. wrote:
>
> >>>>>>
>
> >>>>>>> John:
>
> >>>>>>>
>
> >>>>>>> Thanks for the update. I will be anxious to see the results of
> your analysis.
>
> >>>>>>>
>
> >>>>>>> To the best of my knowledge, the protocol at Pole in place is
> to record all on/off times and to ensure that the personnel at Pole know
> what is going on. I will verify just to make sure.
>
> >>>>>>>
>
> >>>>>>> A couple of questions:
>
> >>>>>>>
>
> >>>>>>> 1. What do you think it will take to track down the the 3.8 Hz
> artifacts that you are seeing to trace the source? It seems that the
> test we've run is inconclusive if we find this ghost but can
> definitively determine its origins.
>
> >>>>>>>
>
> >>>>>>> 2. Is there any way you could guess as to how many dB of
> suppression you would need in our signal to make it drop into your noise
> background, given a good known case of detection, such as was for the
> tests conducted with Skynet-4C this past austral summer? Perhaps I'm
> just being a dumb engineer at this point, but it seems to me that if we
> have a verified interference event coupled to a known point on the
> antenna beam pattern and a known power level into the antenna feed, if
> you could deduce from the data how much suppression would be needed to
> make it drop into the noise, we could then have a hard engineering
> performance target for our future design efforts to relocate the earth
> station to eliminate the interference.
>
> >>>>>>>
>
> >>>>>>> I'm a bit in the dark regarding the possible observing modes
>
> >>>>>>> where long term integration of data from the same spatial
>
> >>>>>>> location would render the above simplistic approach not workable.
>
> >>>>>>> From prior emails, I get the sense that this is a real concern,
>
> >>>>>>> and one that is hard to quantify in a reasonable time period.
>
> >>>>>>> We have a real tough problem to solve in that the logistical
>
> >>>>>>> umbilical effect that prevents us from building a new Skynet
>
> >>>>>>> terminal too far away from the main station also has Dark Sector
>
> >>>>>>> close-in. If we are going to devise an engineering solution
>
> >>>>>>> (say, use a bigger antenna and/or a tapered illumination, use of
>
> >>>>>>> an offset feed; use RF absorbing foam to attenuate side/back
>
> >>>>>>> lobes, etc.), we will need some sort of attenuation suppression
>
> >>>>>>> value to design to. If you're derivations indicate that we
>
> >>>>>>> need>100 dB worth of suppression, then we know that will be
>
> >>>>>>> unattainable and we have a major problem. I'm just trying to
>
> >>>>>>> figure out if there is any logical way to get a handle on this
>
> >>>>> to figure out a solution without taking years to sort this out.
> Any ideas would be most welcome.
>
> >>>>>>>
>
> >>>>>>> Pat
>
> >>>>>>>
>
> >>>>>>> ________________________________________
>
> >>>>>>> From: John Ruhl [ruhl(a)case.edu]
>
> >>>>>>> Sent: Monday, July 16, 2012 4:22 PM
>
> >>>>>>> To: Smith, Patrick D.
>
> >>>>>>> Cc: John Kovac; John Carlstrom; Papitashvili, Vladimir O.
>
> >>>>>>> Subject: Re: skynet test
>
> >>>>>>>
>
> >>>>>>> Pat -
>
> >>>>>>>
>
> >>>>>>> I just wanted to update you on our analysis... we are working
> hard on it. We see some weak peaks at 3.8Hz in some of our channels,
> but it's not clear yet whether that's due to skynet, whether we have the
> normalization correct yet, and therefore what our estimate of potential
> contamination from skynet would be.
>
> >>>>>>>
>
> >>>>>>> We will keep you posted. In the meantime we understand that
> you need to keep skynet as a backup. Please do let us know if/when
> skynet transmits again; so far our winterovers have informed us of two
> transmissions, one that was a mistake and a second that was for a long
> test of connectivity.
>
> >>>>>>>
>
> >>>>>>> thanks,
>
> >>>>>>> John
>
> >>>>>>>
>
> >>>>>>>
>
> >>>>>>> CWRU office: (216)368-4049
>
> >>>>>>>
>
> >>>>>>>
>
> >>>>>>> On Jun 25, 2012, at 6:38 PM, Smith, Patrick D. wrote:
>
> >>>>>>>
>
> >>>>>>>> John -
>
> >>>>>>>> I'm working via Vladimir as the overall lead for working this
>
> >>>>>>>> issue with the astronomy community. I'm handling the
>
> >>>>>>>> contractor interfaces at Pole and on the design/support team
> back here in the US.
>
> >>>>>>>>
>
> >>>>>>>> Points for your consideration:
>
> >>>>>>>>
>
> >>>>>>>> We've made a major physical reconfiguration change of the
>
> >>>>>>>> pointing of the Skynet terminal to point to NATO-4B's
> longitude at 34E.
>
> >>>>>>>> The terminal only has a +/- 10 deg longitude adjust capability.
>
> >>>>>>>> The physical reconfig change puts the functioning of the
>
> >>>>>>>> terminal at risk due to concern of damage, and we only
> implemented this due to the
>
> >>>>>>>> confirmed unsuitability of working via Skynet-4C at 1W this
> winter. I
>
> >>>>>>>> will not want to put the terminal at risk of further damage to
>
> >>>>>>>> reconfig to point at Dark Sector, and then undo to repoint back
>
> >>>>>>>> to 34E, if at all possible.
>
> >>>>>>>>
>
> >>>>>>>> I do have instructions from Brian Stone to ensure that the
>
> >>>>>>>> Skynet terminal can be brought on-line and made operational as
>
> >>>>>>>> an operational contingency in the event of a prolonged outage
>
> >>>>>>>> of the
>
> >>>>>>>> GOES-3 system that puts operations and/or life-safety at the
>
> >>>>>>>> Pole at risk. At this point in time, based on what we know, it
>
> >>>>>>>> would appear much less harmful to use NATO-4B as this
> contingency backup in lieu of Skynet-4C.
>
> >>>>>>>>
>
> >>>>>>>> Our desire is to go operational on NATO-4B this winter, but we
>
> >>>>>>>> won't do so without running the proper evaluation with the
>
> >>>>>>>> astronomy community. It will be Vladimir's call. However, we
>
> >>>>>>>> need to be mindful of my management direction regarding
> emergency back-up capability.
>
> >>>>>>>>
>
> >>>>>>>> In the big picture sense, we do need to find a way to make
> this work.
>
> >>>>>>>> GOES-3 has only about 3 years of life left in it until we need
>
> >>>>>>>> to start seriously looking at disposal to prevent an orbit
>
> >>>>>>>> debris hazard. For NSF to let GOES-3 get stranded in the
>
> >>>>>>>> gravity well at 105W will be a black eye to the Foundation and
>
> >>>>>>>> will be greeted with disapproval from the international space
> operations community.
>
> >>>>>>>> Given this, we need to implement a GOES-3 follow-on.
>
> >>>>>>>> Skynet-4C, with possible use of NATO-4B until we can sort out a
>
> >>>>>>>> suitable "Grid North" earth terminal location to hopefully
>
> >>>>>>>> solve the interference issue with Dark Sector, is the only
> alternative that we have at present.
>
> >>>>>>>>
>
> >>>>>>>> Intelsat and Paradigm/Astrium have been very supportive in
>
> >>>>>>>> working with us to try to implement the NATO-4B work-around and
>
> >>>>>>>> let us substitute it for Skynet-4C until we sort out our
>
> >>>>>>>> permanent earth station. I don't want to unduly prevail on
> their good graces if we can possibly avoid it.
>
> >>>>>>>> I understand your team's commitments for the SPIE conference.
>
> >>>>>>>> I just hope that there aren't any further delays.
>
> >>>>>>>>
>
> >>>>>>>> Best Regards,
>
> >>>>>>>> Pat
>
> >>>>>>>>
>
> >>>>>>>>
>
> >>>>>>>> -----Original Message-----
>
> >>>>>>>> From: John Ruhl [mailto:ruhl@case.edu]
>
> >>>>>>>> Sent: Monday, June 25, 2012 12:41 PM
>
> >>>>>>>> To: Smith, Patrick D.; Papitashvili, Vladimir O.
>
> >>>>>>>> Cc: John Kovac; John Carlstrom
>
> >>>>>>>> Subject: skynet test
>
> >>>>>>>>
>
> >>>>>>>> Pat and Vladimir -
>
> >>>>>>>>
>
> >>>>>>>> I'm writing to update you on the skynet testing; I'm not sure
>
> >>>>>>>> who our actual POC is on this.
>
> >>>>>>>>
>
> >>>>>>>> As you probably know the winterovers ran the test last week.
>
> >>>>>>>> Unfortunately some of the key people on our analysis teams
>
> >>>>>>>> (John Kovac says the same is true for them) are headed to an
>
> >>>>>>>> SPIE conference soon and I expect that we will not be able to
>
> >>>>>>>> fully analyze things until they return in a couple weeks.
>
> >>>>>>>>
>
> >>>>>>>> We'd like to reiterate that even if we do not detect the signal
>
> >>>>>>>> in this roughly 2 hour test, that is not a guarantee that it
>
> >>>>>>>> won't show up in our season-long maps. After analyzing this
>
> >>>>>>>> test, we'd like to step back and think about what other testing
>
> >>>>>>>> or procedures we should put in place, given the limited ability
>
> >>>>>>>> to change the test conditions (ie repoint the skynet antenna
>
> >>>>>>>> significantly) during the winter. There has been some email
>
> >>>>>>>> traffic that we saw via the winter overs indicating that people
>
> >>>>>>>> were thinking about starting regular operations with skynet. I
>
> >>>>>>>> hope we can put that off until after we've all had a chance to
>
> >>>>>>>> talk once we've done our final analysis. If tranmissions are
> or have been made, we want to know the start and stop times, of course.
>
> >>>>>>>>
>
> >>>>>>>> thanks,
>
> >>>>>>>> John
>
> >>>>>>>>
>
> >>>>>>>> CWRU office: (216)368-4049
>
> >>>>>>>>
>
> >>>>>>>>
>
> >>>>>>>
>
> >>>>>>
>
> >>>>>
>
> >>>>>
>
> >>>>> --
>
> >>>>> ___________________________________________________________________
>
> >>>>> John Kovac jmkovac(a)cfa.harvard.edu <mailto:jmkovac@cfa.harvard.edu>
>
> >>>>>
>
> >>>>> Assistant Professor, Astronomy and Physics, Harvard University
>
> >>>>> 160 Concord Ave rm 310, Cambridge MA 02138, 617-496-0611
>
> >>>>
>
> >>>
>
> >>
>
> >
>
--
___________________________________________________________________
John Kovac jmkovac(a)cfa.harvard.edu
Assistant Professor, Astronomy and Physics, Harvard University
160 Concord Ave rm 310, Cambridge MA 02138, 617-496-0611
