PDS_VERSION_ID = PDS3 RECORD_TYPE = STREAM DATA_SET_ID = "MEX-M-MRS-1/2/3-EXT2-2059-V1.0" STANDARD_DATA_PRODUCT_ID = ENB PRODUCER_ID = "SUE" PRODUCT_ID = "M00SUE0L1A_ENB_092260907_00.TXT" PRODUCT_CREATION_TIME = 2012-06-27T13:40:29.000 INSTRUMENT_HOST_ID = "MEX" OBJECT = TEXT PUBLICATION_DATE = 2011-03-10 NOTE = "MEX SUE Experimenter Notes" END_OBJECT = TEXT END From daniel.s.kahan@jpl.nasa.gov Mon Aug 17 10:59:27 2009 Return-Path: Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n7HHxRC11332 for ; Mon, 17 Aug 2009 10:59:27 -0700 (PDT) Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by mail.jpl.nasa.gov (Switch-3.4.1/Switch-3.3.2mp) with ESMTP id n7HHxNnJ032588 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Mon, 17 Aug 2009 17:59:26 GMT Received: from ALTPHYEMBEVSP30.RES.AD.JPL ([128.149.137.84]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Mon, 17 Aug 2009 10:59:23 -0700 Content-Type: multipart/mixed; boundary="_000_79D001DEDB0DEC47A247B110F3E86682062D980361ALTPHYEMBEVSP_" From: "Kahan, Daniel S (332K)" To: "Simpson, Richard A (6520-Affiliate)" CC: "Martin.Paetzold@uni-koeln.de" , "Matthias.Hahn@uni-koeln.de" , "Silvia.Tellmann@uni-koeln.de" , "Thomas.Kuerten@uni-koeln.de" , "Asmar, Sami W (332K)" , "Goltz, Gene L (332K)" Date: Mon, 17 Aug 2009 10:59:23 -0700 Subject: MEX 2009-226 Bistatic Radar Data Thread-Topic: MEX 2009-226 Bistatic Radar Data Thread-Index: AcnBvc7pAV3j4C4FQRakmyn/J88GbQFv/gNwDF1L9rAAM8xNIAEn3t0gAAqqr7ACtgxCEAV/quiA Message-ID: <79D001DEDB0DEC47A247B110F3E86682062D980361@ALTPHYEMBEVSP30.RES.AD.JPL> References: <6.2.5.6.2.20090420054251.01e63e68@jpl.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <79D001DEDB0DEC47A247B110F3E86682062D980361@ALTPHYEMBEVSP30.RES.AD.JPL> acceptlanguage: en-US MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: daniel.s.kahan@jpl.nasa.gov X-AUTH: Authorized Content-Length: 17529 Status: RO --_000_79D001DEDB0DEC47A247B110F3E86682062D980361ALTPHYEMBEVSP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dick, A MEX Bistatic Radar Experiment on DOY 2009-226 was conducted at DSS-14. RSR open-loop data were recorded and played back as follows: - X-band RCP, 1-way - RSR2B3 - 25 kHz, 16 bits - start = 09:07:00 - stop = 10:19:59 - start = 12:29:59 - stop = 14:32:00 - start = 14:59:59 - stop = 15:42:00 - SFDUs = 56,896 and: - S-band RCP, 1-way - RSR2A3 - 25 kHz, 16 bits - start = 09:07:00 - stop = 10:20:00 - start = 12:29:59 - stop = 14:32:00 - start = 14:59:59 - stop = 15:42:00 - SFDUs = 56,900 and: - X-band LCP, 1-way - RSR3B3 - 25 kHz, 16 bits - start = 09:07:00 - stop = 10:20:00 - start = 12:29:59 - stop = 14:32:00 - start = 14:59:59 - stop = 15:42:00 - SFDUs = 56,900 and: - S-band LCP, 1-way - RSR3A3 - 25 kHz, 16 bits - start = 09:07:00 - stop = 10:20:00 - start = 12:29:59 - stop = 14:32:00 - start = 14:59:59 - stop = 15:42:00 - SFDUs = 56,900 plus: - X-band RCP, 1-way - RSR2B4 - 100 kHz, 16 bits - start = 12:52:00 - stop = 13:59:59 - SFDUs = 81,600 and: - S-band RCP, 1-way - RSR2A4 - 100 kHz, 16 bits - start = 12:52:00 - stop = 14:00:00 - SFDUs = 81,620 and: - X-band LCP, 1-way - RSR3B4 - 100 kHz, 16 bits - start = 12:52:00 - stop = 14:00:00 - SFDUs = 81,620 and: - S-band LCP, 1-way - RSR3A4 - 100 kHz, 16 bits - start = 12:52:00 - stop = 14:00:00 - SFDUs = 81,620 These data should now be available for you to query. - Regards, Gene & Danny From wilson.chen@dsn.nasa.gov Fri Aug 14 11:12:06 2009 Return-Path: Received: from DSNOAM-MM.jpl.nasa.gov (dsnoam-mm.jpl.nasa.gov [128.149.207.83]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n7EIC5C07351 for ; Fri, 14 Aug 2009 11:12:05 -0700 (PDT) Received: from dsnoamex1.jpl.nasa.gov (Not Verified[128.149.207.88]) by DSNOAM-MM.jpl.nasa.gov with MailMarshal (v6,5,1,7247) id ; Fri, 14 Aug 2009 11:12:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1D0A.BA47BCDB" Subject: RE: 41 RMDC Radio Science Delivery Date: Fri, 14 Aug 2009 11:12:04 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 41 RMDC Radio Science Delivery Thread-Index: AcoMpLwnrYVmBHKJRlGFcNvJk8Md9ACM2+0gAMn6QCABPE/UIADtPmwgAJkXmSA= References: To: "Chen, Wilson C" , Cc: "!DL-DSN-RMDC" , Content-Length: 5208 Status: RO This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1D0A.BA47BCDB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The listed files have been processed and delivered to: OSCARX://ftp/ras/sc41/odfs/09226O226_14X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09226O226_14S_1s.SC041 Regards, Wilson Chen RMDC Analyst Phone: 626-305-6269 Email: wcchen@jftl.jpl.nasa.gov wilson.chen@dsn.nasa.gov From wilson.chen@dsn.nasa.gov Wed Aug 19 08:51:57 2009 Return-Path: Received: from DSNOAM-MM.jpl.nasa.gov (dsnoam-mm.jpl.nasa.gov [128.149.207.83]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n7JFptC26213 for ; Wed, 19 Aug 2009 08:51:56 -0700 (PDT) Received: from dsnoamex1.jpl.nasa.gov (Not Verified[128.149.207.88]) by DSNOAM-MM.jpl.nasa.gov with MailMarshal (v6,5,1,7247) id ; Wed, 19 Aug 2009 08:51:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA20E4.F88E5B37" Subject: 41 RMDC Radio Science Delivery Date: Wed, 19 Aug 2009 08:51:52 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 41 RMDC Radio Science Delivery Thread-Index: AcoMpLwnrYVmBHKJRlGFcNvJk8Md9ACM2+0gAMn6QCABPE/UIADtPmwgAY88RiA= References: To: Cc: "!DL-DSN-RMDC" , Content-Length: 9445 Status: RO This is a multi-part message in MIME format. ------_=_NextPart_001_01CA20E4.F88E5B37 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The listed files have been processed and delivered to: OSCARX://ftp/ras/sc41/odfs/09224O224_15X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09224O224_15S_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09226O226_14X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09226O226_14S_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09227O228_45X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09227O228_45S_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09228O228_15X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09228O228_15S_1s.SC041 Regards, Wilson Chen RMDC Analyst Phone: 626-305-6269 Email: wcchen@jftl.jpl.nasa.gov wilson.chen@dsn.nasa.gov From jesse.velasco@dsn.nasa.gov Tue Oct 13 07:47:46 2009 Return-Path: Received: from DSNOAM-MM.jpl.nasa.gov (dsnoam-mm.jpl.nasa.gov [128.149.207.83]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n9DElkT00025 for ; Tue, 13 Oct 2009 07:47:46 -0700 (PDT) Received: from dsnoamex1.jpl.nasa.gov (Not Verified[128.149.207.88]) by DSNOAM-MM.jpl.nasa.gov with MailMarshal (v6,4,6,5922) id ; Tue, 13 Oct 2009 07:47:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Noisy S-LCP at DSS 14 for MEX BSR Date: Tue, 13 Oct 2009 07:47:44 -0700 Message-ID: In-Reply-To: <28466.1255397828@magellan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Noisy S-LCP at DSS 14 for MEX BSR Thread-Index: AcpLpb06d7rYsL81TNqv7HDIOZxbbQAbik2w References: <28466.1255397828@magellan> From: "Velasco, Jesse" To: "Dick Simpson 650-723-3525" , , , Cc: "!DL-DSN-MPSETD" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id n9DElkT00025 Content-Length: 880 Status: RO Dick, I will investigate this issue and get back to you. Jesse -----Original Message----- From: Dick Simpson 650-723-3525 [mailto:rsimpson@magellan.stanford.edu] Sent: Monday, October 12, 2009 6:37 PM To: Velasco, Jesse; daniel.s.kahan@jpl.nasa.gov; gene.goltz@jpl.nasa.gov; sami.asmar@jpl.nasa.gov; rsimpson@magellan.stanford.edu Subject: Noisy S-LCP at DSS 14 for MEX BSR Jesse: Since the MEX bistatic radar experiments on 2009/226, the S-LCP channel has been very noisy. The Y-factor this past weekend was only about 4.2 dB compared with 11.4 dB on S-RCP (see attached PDF). Do you know what is causing this and whether any improvement is expected? The experiments in July (2009/184, 185, 193, 199) all seemed to be normal. The new noise reduces our sensitivity by a factor of about 4 on S-Band. That's a lot when our echoes are weak to begin with. Thanks, Dick From jesse.velasco@dsn.nasa.gov Fri Dec 11 22:51:28 2009 Return-Path: Received: from DSNOAM-MM.jpl.nasa.gov (dsnoam-mm.jpl.nasa.gov [128.149.207.83]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nBC6pST25588 for ; Fri, 11 Dec 2009 22:51:28 -0800 (PST) Received: from dsnoamex1.jpl.nasa.gov (Not Verified[128.149.207.88]) by DSNOAM-MM.jpl.nasa.gov with MailMarshal (v6,4,6,5922) id ; Fri, 11 Dec 2009 22:51:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Noisy S-LCP at DSS 14 for MEX BSR Date: Fri, 11 Dec 2009 22:51:22 -0800 Message-ID: In-Reply-To: <200912120058.nBC0w6m24020@magellan.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Noisy S-LCP at DSS 14 for MEX BSR Thread-Index: Acp6xjx7/MaWTEatS9qx1dCI9TEouQAF77zg References: <200912120058.nBC0w6m24020@magellan.stanford.edu> From: "Velasco, Jesse" To: "Dick Simpson 650-723-3525" , , , Cc: "!DL-DSN-MPSETD" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id nBC6pST25588 Content-Length: 2530 Status: RO Dick, Our microwave Engineers cannot find a reason for the S-LCP noise data. I will check with our OEs again and provide you a status. I want to conform the S-LCP noise was during the actual bi-status, or was the noise present during the calibrations too? Jesse -----Original Message----- From: Dick Simpson 650-723-3525 [mailto:rsimpson@magellan.stanford.edu] Sent: Friday, December 11, 2009 4:58 PM To: daniel.s.kahan@jpl.nasa.gov; gene.goltz@jpl.nasa.gov; Velasco, Jesse; rsimpson@magellan.stanford.edu; sami.asmar@jpl.nasa.gov Subject: RE: Noisy S-LCP at DSS 14 for MEX BSR Jesse: Was there ever an explanation pf why the S-LCP noise has been so high at DSS 14? All of the BSR experiments starting with 2009/226 suffered from this problem, but only at DSS 14. We had one experiment at DSS 63 on 2009/245 that was normal. If it was explained, is the noise level back to normal now? We have not done an experiment since 2009/291 and there won't be another MEX BSR until sometime in early 2010; but I have a MEX review next Thursday, and it would be nice to know whether this problem has been solved. Thanks, Dick --------Original Message-------------- From jesse.velasco@dsn.nasa.gov Tue Oct 13 07:47:46 2009 Subject: RE: Noisy S-LCP at DSS 14 for MEX BSR Date: Tue, 13 Oct 2009 07:47:44 -0700 From: "Velasco, Jesse" To: "Dick Simpson 650-723-3525" , , , Cc: "!DL-DSN-MPSETD" Content-Transfer-Encoding: 8bit Content-Length: 880 Status: RO Dick, I will investigate this issue and get back to you. Jesse -----Original Message----- From: Dick Simpson 650-723-3525 [mailto:rsimpson@magellan.stanford.edu] Sent: Monday, October 12, 2009 6:37 PM To: Velasco, Jesse; daniel.s.kahan@jpl.nasa.gov; gene.goltz@jpl.nasa.gov; sami.asmar@jpl.nasa.gov; rsimpson@magellan.stanford.edu Subject: Noisy S-LCP at DSS 14 for MEX BSR Jesse: Since the MEX bistatic radar experiments on 2009/226, the S-LCP channel has been very noisy. The Y-factor this past weekend was only about 4.2 dB compared with 11.4 dB on S-RCP (see attached PDF). Do you know what is causing this and whether any improvement is expected? The experiments in July (2009/184, 185, 193, 199) all seemed to be normal. The new noise reduces our sensitivity by a factor of about 4 on S-Band. That's a lot when our echoes are weak to begin with. Thanks, Dick From rsimpson Sun Dec 13 14:55:11 2009 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id nBDMtBD27742; Sun, 13 Dec 2009 14:55:11 -0800 (PST) Date: Sun, 13 Dec 2009 14:55:11 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <200912132255.nBDMtBD27742@magellan.stanford.edu> To: jesse.velasco@dsn.nasa.gov Subject: RE: Noisy S-LCP at DSS 14 for MEX BSR Cc: DL-DSN-MPSETD@dsn.nasa.gov, daniel.s.kahan@jpl.nasa.gov, gene.goltz@jpl.nasa.gov, rsimpson, sami.asmar@jpl.nasa.gov Content-Length: 1588 Status: O >I want to conform the S-LCP noise was during the actual bi-status, or >was the noise present during the calibrations too? Jesse: It's there all the time. The pre- and post-cal Tsys values on day 199 (the last good day) were 24.33K and 24.30K On day 226 (first bad day) they were 111.01 and 111.14 On day 246 (at DSS 63) they were 24.04K and 24.14K On day 255 (back at DSS 14) they were 110.96K and 110.79K On day 256 (again at DSS 14) they were 110.42K and 111.09K I haven't done the processing on days 260, 284, and 291; but the quick look plots show similar Y factors (less than 5 dB) in the pre- and post-cals; so I'm expecting Tsys to be over 100. We also did an experiment on 2009/234; but there was no signal on either S channel. From the NMC log, I'm guessing that the dichroic reflector was not properly positioned, so we got X-Band only. Just before the second MiniCal, S-Band signals appeared in both polarizations; but it was too late to do science by then. I didn't do S-Band processing, but the quick-look data also show Y factors like 4.3 dB on S-LCP in the post-cal. This is what I would expect if a very bad LNA had been swapped in at the S-LCP front end while the normal LNA was being repaired. If the microwave engineers don't know about it, maybe the S-LCP has simply gone bad and no one else noticed. In any case, losing S-LCP represents a big hit to our measurements, and it would be nice to get the 24K Tsys back again. Let me know if you need more. Regards, Dick From susan.c.kurtik@jpl.nasa.gov Fri Jan 1 20:34:51 2010 Return-Path: Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o024YoT27500 for ; Fri, 1 Jan 2010 20:34:50 -0800 (PST) Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o024YnoM013925 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Fri, 1 Jan 2010 20:34:50 -0800 Received: from ALTPHYEMBEVSP30.RES.AD.JPL ([172.16.0.31]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Fri, 1 Jan 2010 20:34:50 -0800 From: "Kurtik, Susan C (9200)" To: "Simpson, Richard A (6520-Affiliate)" CC: "Bell, Julia L (9210)" , "Kurtik, Susan C (9200)" Date: Fri, 1 Jan 2010 20:34:47 -0800 Subject: Re: NASA/MEX/Stanford Site Review: d_bsr_report.ppt Thread-Topic: NASA/MEX/Stanford Site Review: d_bsr_report.ppt Thread-Index: AcqChGEvYGqEn7DPQ9GBR8qtGyHyjAI4Iitq Message-ID: In-Reply-To: <200912212127.nBLLRJj17578@magellan.stanford.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7640CE7818D2SusanCKurtikjplnasagov_" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: susan.c.kurtik@jpl.nasa.gov X-AUTH: Authorized Content-Length: 7195 Status: RO --_000_C7640CE7818D2SusanCKurtikjplnasagov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dick - Thanks! Hope you had a nice holiday and best wishes for a very successful 2010! The NOPEs are following up on the DRs on DOY 255-256, it appears from reading the DRs that there were problems with the IF switch to the open loop equipment (the IF switch for the closed loop receivers were fine). I was not able to find the high noise temperature DRs, so I have asked the NOPEs to follow up on this issue too. Almost everyone was gone over the holidays, so I haven't gotten a response back yet. Thanks for your nice comments about the NOPEs. I understand that it is difficult to get answers, but I don't like them to drop the ball and so I appreciate your letting me know when things fall through the cracks. BTW, the DR109690 for DOY255 is closed with the root cause being the FSP IF switch that sends the signal to the RSR receiver. Their troubleshooting efforts confirmed there was no signal going to the RSR, yet there was a signal to the DTT closed loop receiver. Since the closed loop signal is transferred via the DTT IF switch (vs the open loop signal via the FSP IF switch), it is assumed that the FSP IF switch had an unknown problem. There was a question whether the DR109692 on DOY256 was related to the DOY255 DR, but that is not the case. On DOY256, the DR indicates that neither the closed loop or the open loop receivers (DTT or RSR) were able to acquire the signal and there was a hardware problem with the coax which I did not understand by reading the DR so I have asked the NOPE to follow up with more details. I will let you know when I hear back. Happy New Year! Best regards, sooz On 12/21/09 1:27 PM, "Dick Simpson 650-723-3525" wrote: >The NOPEs are investigating the problems documented in your report >and we will let you know the results of their analysis when it is >complete. Thanks, Sooz: I want to be clear that I have been very happy with the support provided by both the NOPEs and the schedulers. Both work in difficult environments. The NOPE issues (particularly the DRs from days 255 and 256) and the unusually high noise temperature on S-LCP are probably just lapses in communication -- but a little out of character given that Jesse usually follows up very quickly. Ruben is new, but he's been more successful in getting us 70-m time than I would have expected. An experiment per week (average) is about all we can handle, and the ESA baseline is one every two weeks (but we're making up for NO experiments during 2007 when MEX was at maximum range). Thanks for taking time to join in the review. If you, Julia, or anyone else needs additional information, just let me know. Regards, Dick -- Susan C. Kurtik Jet Propulsion Laboratory Deep Space Network Mission Support Manager 818 354-3598 office 818 687-7903 cell Don't leave earth without us From rsimpson Mon Jan 4 16:21:41 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o050LeH17059; Mon, 4 Jan 2010 16:21:40 -0800 (PST) Date: Mon, 4 Jan 2010 16:21:40 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <201001050021.o050LeH17059@magellan.stanford.edu> To: susan.c.kurtik@jpl.nasa.gov Subject: Re: NASA/MEX/Stanford Site Review: d_bsr_report.ppt Cc: julia.l.bell@jpl.nasa.gov, rsimpson Content-Length: 2212 Status: R >BTW, the DR109690 for DOY255 is closed with the root cause being the FSP IF >switch that sends the signal to the RSR receiver. Their troubleshooting >efforts confirmed there was no signal going to the RSR, yet there was a >signal to the DTT closed loop receiver. Since the closed loop signal is >transferred via the DTT IF switch (vs the open loop signal via the FSP IF >switch), it is assumed that the FSP IF switch had an unknown problem. Usually this means that someone disconnected a cable and forgot to put it back. The fact that signals were as expected on day 260 suggests that the 'unknown' problem had been fixed by then. >There was a question whether the DR109692 on DOY256 was related to the >DOY255 DR, but that is not the case. On DOY256, the DR indicates that >neither the closed loop or the open loop receivers (DTT or RSR) were able >to acquire the signal and there was a hardware problem with the coax which >I did not understand by reading the DR so I have asked the NOPE to follow >up with more details. I will let you know when I hear back. The reports I received from Gene Goltz said that an S-RCP signal was received at the closed loop receiver on both days and that there was no S-RCP at the open loop receivers both days. But I see that there was a TRK-2-18 for each band on 255 and only an X-Band file on 256. The important bottom line is that the problem has been fixed. >I was not able to find the high noise temperature DRs, >so I have asked the NOPEs to follow up on this issue too. This one, so far as I can tell, is still with us. Jesse investigated and reported on 11 December that "Our microwave Engineers cannot find a reason for the S-LCP noise data. I will check with our OEs again and provide you a status." It's possible the problem simply went away; our last experiment was on 18 October, but I'm surprised no one noticed its coming and going. My first report was on 12 October, roughly two months after it appeared (we got behind in processing because we were doing so many experiments and had a lot of travel). Thanks for following up and letting me know. Happy new year, Dick From rsimpson Fri Jan 8 16:06:23 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o0906NW29949; Fri, 8 Jan 2010 16:06:23 -0800 (PST) Date: Fri, 8 Jan 2010 16:06:23 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <201001090006.o0906NW29949@magellan.stanford.edu> To: sami.w.asmar@jpl.nasa.gov Subject: Re: MEX BSR and GRV DSN Data Cc: rsimpson, scott.riley@dsn.nasa.gov, susan.c.kurtik@jpl.nasa.gov Content-Length: 540 Status: RO >I am not sure if you received any feedback on this or not, >but just in case ... It took me a while to figure out what this was about. Although the configuration was unusual, we collected good data on 2009/199; so I have not given this much thought. I'm more concerned about the cabling(?) problems we had on 2009/255 and 2009/256 when there was no S-RCP to the open-loop equipment. And most concerned about the apparent x5 increase in S-LCP system temperature during ALL of the experiments starting with 2009/226. From susan.c.kurtik@jpl.nasa.gov Sun Jan 10 10:16:34 2010 Return-Path: Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0AIGYT03490 for ; Sun, 10 Jan 2010 10:16:34 -0800 (PST) Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o0AIGXET001634 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Sun, 10 Jan 2010 10:16:33 -0800 Received: from ALTPHYEMBEVSP30.RES.AD.JPL ([172.16.0.31]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Sun, 10 Jan 2010 10:16:33 -0800 From: "Kurtik, Susan C (9200)" To: "Simpson, Richard A (6520-Affiliate)" , "Asmar, Sami W (332K)" CC: "scott.riley@dsn.nasa.gov" , "Kurtik, Susan C (9200)" Date: Sun, 10 Jan 2010 10:16:30 -0800 Subject: Re: MEX BSR and GRV DSN Data Thread-Topic: MEX BSR and GRV DSN Data Thread-Index: AcqQv5gfIcXor/WLR8K37fA1AFJ85QBYW/vR Message-ID: In-Reply-To: <201001090006.o0906NW29949@magellan.stanford.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C76F597E81E6CSusanCKurtikjplnasagov_" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: susan.c.kurtik@jpl.nasa.gov X-AUTH: Authorized Content-Length: 9569 Status: RO --_000_C76F597E81E6CSusanCKurtikjplnasagov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dick - This is the analysis and corrective actions taken for the anomalies that you noted. I hope this helps. 1. SNT Increase analysis Summary by our Goldstone expert: From: Bracamonte, Larry H For DOY 234, 255, 256, 260, 284 and 291 the operator set the diode modulation frequency (MFQ) to "ON" for some of the time. If System Noise Temperature (SNT) measurement is enabled with the MFQ=3DON, the Downlink Channel will usually report an SNT value of 100 Kelvin since the diode is not being cycled on and off at a predicted rate. If there is some level difference detected between the periods when the Downlink Channel expects the diode to be on compared with the periods the diode is expected to be off, the Downlink Channel could report an SNT much greater than 100 Kelvin. When the MFQ is set to "ON" and the SNT is enabled, the Downlink Channel is not reporting the actual SNT. Summary by Scott Riley (lead NOPE): To summarize what Larry has provided above, with the "MFQ=3DON" (rather than cycling on and off) for the Bi-static configuration (which is what the Radio Science team requires), the nominal value that would be recorded for the SNT is 100K. So, from what we can tell based on the configuration the nominal SNT should be about 100K. However, if there was a spurious signal, the system could report an SNT that is much higher than 100K. However, Larry pointed out that if there was truly a problem there would have been several missions complaining, so this was more than likely some level being detected (RFI) that caused the SNT value to Jump. 2, DOY255 and 256: DR analysis have indicated that neither of these problems are due to cable switches 1. G109690 The IF switch to the RSR had a bad output amplifier. It was replaced on 1 Oct 2009. 2. G109692 This was a problem with a stuck microwave switch in the S Band UWV signal distribution assembly. The engineers have not been able to reproduce the problem Larry's analysis: DR G109692 on DOY 256: Downlink Channel 3 (DC03) reported a stable total power gain control value of about 0.77 volts and that voltage did not change when the LNA input was changed from sky to ambient load or when the diode was enabled and disabled. During subsequent testing, when microwave switch 12 was in position A, DC03 reported a voltage of 0.83. Switch 12 monitor data indicated it was in the correct B position during the support though. During normal operation, the DC03 total power gain control value is greater than 1.5 volts and varies with changes in input power level. Scott's summary: The indications are that a microwave switch was stuck. The monitor data showed that it was correctly configured but Larry states that the measurements he detected shows that it was in fact not. The station has tested this UWV switch and verified that when the switch is in the incorrect position they receive the exact indications as was seen during the experiment, but what they cannot do is get the switch to fail again into that position. ====================================== On /Friday8/108 4:06 PM, "Dick Simpson 650-723-3525" wrote: >I am not sure if you received any feedback on this or not, >but just in case ... It took me a while to figure out what this was about. Although the configuration was unusual, we collected good data on 2009/199; so I have not given this much thought. I'm more concerned about the cabling(?) problems we had on 2009/255 and 2009/256 when there was no S-RCP to the open-loop equipment. And most concerned about the apparent x5 increase in S-LCP system temperature during ALL of the experiments starting with 2009/226. -- Susan C. Kurtik Jet Propulsion Laboratory Deep Space Network Mission Support Manager 818 354-3598 office 818 687-7903 cell Don't leave earth without us From rsimpson Sun Jan 10 16:42:58 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o0B0gvL09770; Sun, 10 Jan 2010 16:42:57 -0800 (PST) Date: Sun, 10 Jan 2010 16:42:57 -0800 (PST) From: Dick Simpson 650-723-3525 Message-ID: <9769.1263170578@magellan> Mime-Version: 1.0 To: susan.c.kurtik@jpl.nasa.gov, rsimpson@magellan.stanford.edu, sami.w.asmar@jpl.nasa.gov, scott.riley@dsn.nasa.gov, lbracamonte@gdscc.nasa.gov, rsimpson Subject: MEX BSR High SNT Content-Type: multipart/mixed; boundary="-" Content-Length: 728406 Status: RO This is a MIME encoded message. Decode it with "munpack" or any other MIME reading software. Mpack/munpack is available via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/ --- >1. SNT Increase analysis >Summary by our Goldstone expert: >From: Bracamonte, Larry H >For DOY 234, 255, 256, 260, 284 and 291 the operator set the diode >modulation frequency (MFQ) to "ON" for some of the time. If System >Noise Temperature (SNT) measurement is enabled with the MFQ=ON, the >Downlink Channel will usually report an SNT value of 100 Kelvin since >the diode is not being cycled on and off at a predicted rate. If there >is some level difference detected between the periods when the Downlink >Channel expects the diode to be on compared with the periods the >diode is expected to be off, the Downlink Channel could report an SNT >much greater than 100 Kelvin. When the MFQ is set to "ON" and the SNT >is enabled, the Downlink Channel is not reporting the actual SNT. > >Summary by Scott Riley (lead NOPE): >To summarize what Larry has provided above, with the "MFQ=ON" (rather >than cycling on and off) for the Bi-static configuration (which is what >the Radio Science team requires), the nominal value that would be >recorded for the SNT is 100K. So, from what we can tell based on the >configuration the nominal SNT should be about 100K. However, if there >was a spurious signal, the system could report an SNT that is much >higher than 100K. However, Larry pointed out that if there was truly >a problem there would have been several missions complaining, so this >was more than likely some level being detected (RFI) that caused the >SNT value to Jump. Susan: Thanks for the feedback regarding the high SNT. I have a great deal of respect for Larry; he helped us develop the procedure which we use to do the calibrations for the bistatic radar. I've not met Scott. I don't believe they understand the problem. Note, first, that the issue is with S-LCP. Note also that we use essentially the same calibration procedure on X-RCP, X-LCP, S-RCP, and S-LCP; until 2009/226, they all produced comparable results. The problem is not with the use of the noise diode; we see the high SNT during the pre-cal and post-cal with the ambient load -- as well as during the track with the noise diode. I sent the attached PDF to Jesse at the end of October; it shows the high SNT on S-LCP while we have normal performance on S-RCP during the pre-cal. A Y-factor of 4.2 dB is not normal for S-LCP. These figures were derived from RSR data. We do not use DSN Monitor data because the closed-loop receivers are continually being reconfigured during a bistatic radar experiment so that we can control the noise diodes. There is no interfering signal; we compute spectra which show no narrow band signal within our 25 kHz passband during the pre-cal, the post-cal or the track. If the interference were broad band, I would expect it to affect both RCP and LCP. S-RCP is normal (Y-factor 11.4 dB). We did one experiment using DSS 63 during this string of DSS 14 experiments. It was on 2009/245; DSS 63 uses the same procedure as DSS 14, and DSS 63 was normal on all channels (S-LCP Y-factor was about 11 dB). I can send those plots if they would be of interest. As for other mission complaints, how many use S-LCP regularly? My first guess was that something happened to the DSS 14 S-LCP LNA between 2009/199 (the last normal BSR at 14) and 2009/226. Now that I have completed processing our backlog of BSR data, the S-LCP Mars echo powers I am deriving are suspiciously large starting 2009/226 (except for the DSS 63 experiment on 2009/245). It's possible that the LNA is OK but that large amounts of noise are being added in some downconversion or IF stage before the signal gets to the RSR (or in the RSR itself). Significant noise added after the LNA would cause me to overestimate the echo power. This needs further investigation, with focus on the S-LCP path from LNA all the way to the RSR. Regards, Dick PS: I didn't see Larry on your distribution; but I'm adding him with an address I located from about 5 years ago. I assume Scott can forward if I have it wrong. --- Content-Type: application/octet-stream; name="MEX_BSR_09284.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="MEX_BSR_09284.pdf" Content-MD5: B937DIQLR7A3FdgyZ8NQmg== JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqlV9tuIzcMfddX6NFbIFqR1IV6bC4F0naTLeyi ... From susan.c.kurtik@jpl.nasa.gov Sun Jan 10 17:12:57 2010 Return-Path: Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0B1CvT09851 for ; Sun, 10 Jan 2010 17:12:57 -0800 (PST) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o0B1CnZi012166 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Sun, 10 Jan 2010 17:12:50 -0800 Received: from ALTPHYEMBEVSP30.RES.AD.JPL ([172.16.0.31]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Sun, 10 Jan 2010 17:12:50 -0800 From: "Kurtik, Susan C (9200)" To: "Simpson, Richard A (6520-Affiliate)" , "Asmar, Sami W (332K)" , "scott.riley@dsn.nasa.gov" , "lbracamonte@gdscc.nasa.gov" , "Bracamonte, Larry H (9200-Affiliate)" CC: "Kurtik, Susan C (9200)" , !DL-DSN-MPSETD , "Bell, Julia L (9210)" Date: Sun, 10 Jan 2010 17:12:48 -0800 Subject: Re: MEX BSR High SNT Thread-Topic: MEX BSR High SNT Thread-Index: AcqSVwfcN6Lnlpw+QP+vIK/ccyTeHAABCg4V Message-ID: In-Reply-To: <9769.1263170578@magellan> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C76FBB1081EA4SusanCKurtikjplnasagov_" MIME-Version: 1.0 X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: susan.c.kurtik@jpl.nasa.gov X-AUTH: Authorized Content-Length: 11128 Status: RO --_000_C76FBB1081EA4SusanCKurtikjplnasagov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dick - Thanks for the new information and for adding Larry to the distribution, th= at address should work but I have also added his JPL X500 address. Larry = is the expert in this area and will be the best to provide further analysis= . On /Sunday10/1010 4:42 PM, "Dick Simpson 650-723-3525" wrote: >1. SNT Increase analysis >Summary by our Goldstone expert: >From: Bracamonte, Larry H >For DOY 234, 255, 256, 260, 284 and 291 the operator set the diode >modulation frequency (MFQ) to "ON" for some of the time. If System >Noise Temperature (SNT) measurement is enabled with the MFQ=3DON, the >Downlink Channel will usually report an SNT value of 100 Kelvin since >the diode is not being cycled on and off at a predicted rate. If there >is some level difference detected between the periods when the Downlink >Channel expects the diode to be on compared with the periods the >diode is expected to be off, the Downlink Channel could report an SNT >much greater than 100 Kelvin. When the MFQ is set to "ON" and the SNT >is enabled, the Downlink Channel is not reporting the actual SNT. > >Summary by Scott Riley (lead NOPE): >To summarize what Larry has provided above, with the "MFQ=3DON" (rather >than cycling on and off) for the Bi-static configuration (which is what >the Radio Science team requires), the nominal value that would be >recorded for the SNT is 100K. So, from what we can tell based on the >configuration the nominal SNT should be about 100K. However, if there >was a spurious signal, the system could report an SNT that is much >higher than 100K. However, Larry pointed out that if there was truly >a problem there would have been several missions complaining, so this >was more than likely some level being detected (RFI) that caused the >SNT value to Jump. Susan: Thanks for the feedback regarding the high SNT. I have a great deal of respect for Larry; he helped us develop the procedure which we use to do the calibrations for the bistatic radar. I've not met Scott. I don't believe they understand the problem. Note, first, that the issue is with S-LCP. Note also that we use essentially the same calibration procedure on X-RCP, X-LCP, S-RCP, and S-LCP; until 2009/226, they all produced comparable results. The problem is not with the use of the noise diode; we see the high SNT during the pre-cal and post-cal with the ambient load -- as well as during the track with the noise diode. I sent the attached PDF to Jesse at the end of October; it shows the high SNT on S-LCP while we have normal performance on S-RCP during the pre-cal. A Y-factor of 4.2 dB is not normal for S-LCP. These figures were derived from RSR data. We do not use DSN Monitor data because the closed-loop receivers are continually being reconfigured during a bistatic radar experiment so that we can control the noise diodes. There is no interfering signal; we compute spectra which show no narrow band signal within our 25 kHz passband during the pre-cal, the post-cal or the track. If the interference were broad band, I would expect it to affect both RCP and LCP. S-RCP is normal (Y-factor 11.4 dB). We did one experiment using DSS 63 during this string of DSS 14 experiments. It was on 2009/245; DSS 63 uses the same procedure as DSS 14, and DSS 63 was normal on all channels (S-LCP Y-factor was about 11 dB). I can send those plots if they would be of interest. As for other mission complaints, how many use S-LCP regularly? My first guess was that something happened to the DSS 14 S-LCP LNA between 2009/199 (the last normal BSR at 14) and 2009/226. Now that I have completed processing our backlog of BSR data, the S-LCP Mars echo powers I am deriving are suspiciously large starting 2009/226 (except for the DSS 63 experiment on 2009/245). It's possible that the LNA is OK but that large amounts of noise are being added in some downconversion or IF stage before the signal gets to the RSR (or in the RSR itself). Significant noise added after the LNA would cause me to overestimate the echo power. This needs further investigation, with focus on the S-LCP path from LNA all the way to the RSR. Regards, Dick PS: I didn't see Larry on your distribution; but I'm adding him with an address I located from about 5 years ago. I assume Scott can forward if I have it wrong. -- Susan C. Kurtik Jet Propulsion Laboratory Deep Space Network Mission Support Manager 818 354-3598 office 818 687-7903 cell Don't leave earth without us From scott.riley@dsn.nasa.gov Sun Jan 10 17:21:14 2010 Return-Path: Received: from DSNOAM-MM.jpl.nasa.gov (dsnoam-mm.jpl.nasa.gov [128.149.207.83]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0B1LDT09863 for ; Sun, 10 Jan 2010 17:21:13 -0800 (PST) Received: from dsnoamex1.jpl.nasa.gov (Not Verified[128.149.207.88]) by DSNOAM-MM.jpl.nasa.gov with MailMarshal (v6,4,6,5922) id ; Sun, 10 Jan 2010 17:21:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA925C.663D6C6E" Subject: RE: MEX BSR High SNT Date: Sun, 10 Jan 2010 17:20:30 -0800 Message-ID: <4CFC28C1247FEB4A982802DEA78252F8B6A95C@dsnoamex1.jpl.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEX BSR High SNT Thread-Index: AcqSVxxa4gIYsNTVT7qd0qTw0zZtZwABSc4T References: <9769.1263170578@magellan> From: "Riley, Scott L" To: "Dick Simpson 650-723-3525" , , , "Bracamonte, Larry H" Content-Length: 11349 Status: RO This is a multi-part message in MIME format. ------_=_NextPart_001_01CA925C.663D6C6E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dick, Sounds good, I will work with Larry to se if we can isolate some interference in the S-LCP path. --Scott From rsimpson Sun Jan 10 17:33:41 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o0B1XeB09917; Sun, 10 Jan 2010 17:33:40 -0800 (PST) Date: Sun, 10 Jan 2010 17:33:40 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <201001110133.o0B1XeB09917@magellan.stanford.edu> To: susan.c.kurtik@jpl.nasa.gov Subject: Re: MEX BSR High SNT Cc: DL-DSN-MPSETD@dsn.nasa.gov, Larry.H.Bracamonte@jpl.nasa.gov, julia.l.bell@jpl.nasa.gov, rsimpson, sami.w.asmar@jpl.nasa.gov, scott.riley@dsn.nasa.gov Content-Length: 1126 Status: R >Thanks for the new information and for adding Larry to the distribution, >that address should work but I have also added his JPL X500 address. >Larry is the expert in this area and will be the best to provide further >analysis. Without Larry, we never would have got this experiment off the ground. I agree with your assessment. And I see a message from Scott that seems to concur. At first glance, the symptoms look very much like a bad microwave front end. But the fact that my standard analysis gives S-LCP Mars echo powers that are consistently a factor of 2 higher than I would normally expect suggests that there's something noisy after the LNA and before the RSR. It might be one of those switches or amplifiers. It's interesting that it soured between experiments on days 199 and 226; and it has remained very much the same ever since (until our last experiment on 291). I'm happy to provide more examples or assist in any additional tests. I think the PDF I just sent explains it all pretty well, however. S-LCP simply doesn't have a good Y-factor when observed through the RSR. From scott.riley@dsn.nasa.gov Mon Jan 11 10:10:34 2010 Return-Path: Received: from DSNOAM-MM.jpl.nasa.gov (dsnoam-mm.jpl.nasa.gov [128.149.207.83]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0BIAYT12654 for ; Mon, 11 Jan 2010 10:10:34 -0800 (PST) Received: from dsnoamex1.jpl.nasa.gov (Not Verified[128.149.207.88]) by DSNOAM-MM.jpl.nasa.gov with MailMarshal (v6,4,6,5922) id ; Mon, 11 Jan 2010 10:10:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MEX BSR High SNT Date: Mon, 11 Jan 2010 10:10:04 -0800 Message-ID: <4CFC28C1247FEB4A982802DEA78252F8C9C018@dsnoamex1.jpl.nasa.gov> In-Reply-To: <9769.1263170578@magellan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEX BSR High SNT Thread-Index: AcqSVxxa4gIYsNTVT7qd0qTw0zZtZwAkHCTw References: <9769.1263170578@magellan> From: "Riley, Scott L" To: "Dick Simpson 650-723-3525" , , , "Bracamonte, Larry H" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id o0BIAYT12654 Content-Length: 5087 Status: RO Dick, Just spoke with GDSCC this morning and they are going to do the following: 1.) Replace the stuck microwave switch. As I mentioned they could not get it to fail, but when they placed it in the incorrect position they received the same measurements as if it had failed even though the monitor data showed it had not. Therefore, as a result they are going to replace it to minimize this from reoccurring in the future. 2.) They would also like to know when the next MEX Bi-static activity is. This is due to they want to Y-Factor both the S-RCP and S-LCP path prior to the next activity. Thanks, --Scott -----Original Message----- From: Dick Simpson 650-723-3525 [mailto:rsimpson@magellan.stanford.edu] Sent: Sunday, January 10, 2010 4:43 PM To: susan.c.kurtik@jpl.nasa.gov; rsimpson@magellan.stanford.edu; sami.w.asmar@jpl.nasa.gov; Riley, Scott L; Bracamonte, Larry H; rsimpson@magellan.stanford.edu Subject: MEX BSR High SNT >1. SNT Increase analysis >Summary by our Goldstone expert: >From: Bracamonte, Larry H >For DOY 234, 255, 256, 260, 284 and 291 the operator set the diode >modulation frequency (MFQ) to "ON" for some of the time. If System >Noise Temperature (SNT) measurement is enabled with the MFQ=ON, the >Downlink Channel will usually report an SNT value of 100 Kelvin since >the diode is not being cycled on and off at a predicted rate. If there >is some level difference detected between the periods when the Downlink >Channel expects the diode to be on compared with the periods the diode >is expected to be off, the Downlink Channel could report an SNT much >greater than 100 Kelvin. When the MFQ is set to "ON" and the SNT is >enabled, the Downlink Channel is not reporting the actual SNT. > >Summary by Scott Riley (lead NOPE): >To summarize what Larry has provided above, with the "MFQ=ON" (rather >than cycling on and off) for the Bi-static configuration (which is what >the Radio Science team requires), the nominal value that would be >recorded for the SNT is 100K. So, from what we can tell based on the >configuration the nominal SNT should be about 100K. However, if there >was a spurious signal, the system could report an SNT that is much >higher than 100K. However, Larry pointed out that if there was truly a >problem there would have been several missions complaining, so this was >more than likely some level being detected (RFI) that caused the SNT >value to Jump. Susan: Thanks for the feedback regarding the high SNT. I have a great deal of respect for Larry; he helped us develop the procedure which we use to do the calibrations for the bistatic radar. I've not met Scott. I don't believe they understand the problem. Note, first, that the issue is with S-LCP. Note also that we use essentially the same calibration procedure on X-RCP, X-LCP, S-RCP, and S-LCP; until 2009/226, they all produced comparable results. The problem is not with the use of the noise diode; we see the high SNT during the pre-cal and post-cal with the ambient load -- as well as during the track with the noise diode. I sent the attached PDF to Jesse at the end of October; it shows the high SNT on S-LCP while we have normal performance on S-RCP during the pre-cal. A Y-factor of 4.2 dB is not normal for S-LCP. These figures were derived from RSR data. We do not use DSN Monitor data because the closed-loop receivers are continually being reconfigured during a bistatic radar experiment so that we can control the noise diodes. There is no interfering signal; we compute spectra which show no narrow band signal within our 25 kHz passband during the pre-cal, the post-cal or the track. If the interference were broad band, I would expect it to affect both RCP and LCP. S-RCP is normal (Y-factor 11.4 dB). We did one experiment using DSS 63 during this string of DSS 14 experiments. It was on 2009/245; DSS 63 uses the same procedure as DSS 14, and DSS 63 was normal on all channels (S-LCP Y-factor was about 11 dB). I can send those plots if they would be of interest. As for other mission complaints, how many use S-LCP regularly? My first guess was that something happened to the DSS 14 S-LCP LNA between 2009/199 (the last normal BSR at 14) and 2009/226. Now that I have completed processing our backlog of BSR data, the S-LCP Mars echo powers I am deriving are suspiciously large starting 2009/226 (except for the DSS 63 experiment on 2009/245). It's possible that the LNA is OK but that large amounts of noise are being added in some downconversion or IF stage before the signal gets to the RSR (or in the RSR itself). Significant noise added after the LNA would cause me to overestimate the echo power. This needs further investigation, with focus on the S-LCP path from LNA all the way to the RSR. Regards, Dick PS: I didn't see Larry on your distribution; but I'm adding him with an address I located from about 5 years ago. I assume Scott can forward if I have it wrong. From rsimpson Wed Jan 13 15:12:03 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o0DNC3t18206; Wed, 13 Jan 2010 15:12:03 -0800 (PST) Date: Wed, 13 Jan 2010 15:12:03 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <201001132312.o0DNC3t18206@magellan.stanford.edu> To: LBracamonte@gdscc.nasa.gov, sami.w.asmar@jpl.nasa.gov, scott.riley@dsn.nasa.gov, susan.c.kurtik@jpl.nasa.gov Subject: RE: MEX BSR High SNT Cc: rsimpson Content-Length: 819 Status: R >1.) Replace the stuck microwave switch. As I mentioned they could not >get it to fail, but when they placed it in the incorrect position they >received the same measurements as if it had failed even though the >monitor data showed it had not. Therefore, as a result they are going to >replace it to minimize this from reoccurring in the future. Sounds like a good idea. >2.) They would also like to know when the next MEX Bi-static activity >is. This is due to they want to Y-Factor both the S-RCP and S-LCP path >prior to the next activity. The current DSN schedule shows MEX BSR on days 041, 050, 051, and 055, all at DSS 14. Then there's a long gap until day 106 when there's a tentative experiment at DSS 63. I'm not aware of BSR on any other missions; but CASSINI has done a few in the past. From LBracamonte@gdscc.nasa.gov Tue Jan 19 14:53:08 2010 Return-Path: Received: from gex1.gdscc.nasa.gov (gex1.gdscc.nasa.gov [158.154.3.45]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0JMr7N06296 for ; Tue, 19 Jan 2010 14:53:08 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MEX BSR High SNT Date: Tue, 19 Jan 2010 14:53:26 -0800 Message-ID: In-Reply-To: <4CFC28C1247FEB4A982802DEA78252F8C9C018@dsnoamex1.jpl.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEX BSR High SNT Thread-Index: AcqSVxxa4gIYsNTVT7qd0qTw0zZtZwAkHCTwAZk2T6A= References: <9769.1263170578@magellan> <4CFC28C1247FEB4A982802DEA78252F8C9C018@dsnoamex1.jpl.nasa.gov> From: "Bracamonte, Larry H" To: "Riley, Scott L" Cc: "Dick Simpson 650-723-3525" , , , "Kahan, Daniel S (332K)" , "Stroup, Steven" , "Perez, Jose" , "Hofhine, Douglas" , "Allen, David" , "Massey, Kim" , "Anderson, Terry E" , "Creech, Ronald E" , "Matossian, Harout" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id o0JMr7N06296 Content-Length: 8770 Status: RO Scott, Reviewed Microwave Anisotropy Probe (MAP) spacecraft tracks near the MEX bi-static support dates and the Downlink Channel measured system noise temperature (SNT) and carrier-to-noise (Pc/N0) values indicate the DSS14 S-HEMT was probably operating normally during the MEX supports. The diplexer position SNT values varied nominally with antenna elevation angle changes during the MAP supports from a low of about 26 to a high of about 40 Kelvin. The MAP Pc/N0 varied from about 52 to 54 dB-Hz. Daniel Kahan provided the RSR channel numbers used for the MEX bi-static supports in question. The DOY 234 MEX support used RSR1A. Equipment status GE090178 2009 247 22:04 stated: "No input to channel A from IF switch 1. RSR1B is operational." (Note: The IF switch number should have read 2 vice 1) Since awareness of an FSP IF switch problem usually depends on investigation following a user complaint, it is possible the output to RSR1A was bad on DOY 234. The rest of the impacted MEX bi-static supports used RSR3A. During testing with an RTSG signal, it was found that RSR3A degraded the DSS14 S-HEMT low noise system noise Y-factor by about 1.4 dB (9.7 dB vice 11.1 dB). Pc/N0 was degraded about 2.2 dB in the sky position with the injected signal carrier-to-noise at about 55 dB-Hz (measured by spectrum analyzer at I.F., Downlink Channel 1 and the other RSR channels). The degraded system noise Y-factor with RSR3A cleared after the RSR3 "CNV" board was removed and replaced with a board from RSR2. The original RSR3 "CNV" board was re-installed and the degraded Y-factor problem was still no longer present. During subsequent tests the RSR3A system noise Y-factor remained at about 11.1 dB. The RSR sub-channel bandwidths used during the tests were 1KHz, 2KHz, 25KHz and 100 KHz. The DOY 256 support may have been impacted by a stuck Microwave Subsystem Control (USC) switch 12 (physical switch 1650/UWV-115S3). That switch has been replaced. The reported 7 dB degradation of DSS14 S-HEMT low noise system noise Y-factor has not been duplicated during testing. It is possible the problem that caused the 1.4 dB RSR3A degraded performance noted during testing was worse during the impacted supports. Since the corrective action was effectively reseating the "CNV" board, recommend using another channel if possible. At least for now, suggest operations record the S-HEMT 70K stage and 15K stage cryogenic temperatures during pre-cal and post-cal of future MEX bi-static supports. The S-HEMT Temperature Indicator is located in SPC-10, room 200, grid V-12 in cabinet 3479/UWV-001. S-HEMT Temperature Indicator "A" should be less than 070 (currently 066.5) and "B" should be less than 15 (currently 13.68). Also suggest that during pre-cal, operations measure the DSS14 S-HEMT low noise SNT using a Downlink Channel with the center frequency set to 2250 MHz to avoid the impact of the Satellite Radio RFI on the results. (Note: Since the Satellite Radio RFI is always present, the RSR "CNF" display "Digitizer Info ADC Amp:" parameter is also impacted so that parameter can't be used check the S-HEMT system noise Y-factor with the RSR set to the MEX frequency. The S-band MASER effectively filters out the Satellite Radio RFI so if the Downlink Channel is used to measure the SRCP SNT at the MEX frequency, it should give a reasonable result.) Larry Bracamonte Phone: 760-255-8286 Fax: 760-255-8438 Email: LBracamonte@gdscc.nasa.gov -----Original Message----- From: Riley, Scott L Sent: Monday, January 11, 2010 10:10 AM To: Dick Simpson 650-723-3525; susan.c.kurtik@jpl.nasa.gov; sami.w.asmar@jpl.nasa.gov; Bracamonte, Larry H Subject: RE: MEX BSR High SNT Dick, Just spoke with GDSCC this morning and they are going to do the following: 1.) Replace the stuck microwave switch. As I mentioned they could not get it to fail, but when they placed it in the incorrect position they received the same measurements as if it had failed even though the monitor data showed it had not. Therefore, as a result they are going to replace it to minimize this from reoccurring in the future. 2.) They would also like to know when the next MEX Bi-static activity is. This is due to they want to Y-Factor both the S-RCP and S-LCP path prior to the next activity. Thanks, --Scott -----Original Message----- From: Dick Simpson 650-723-3525 [mailto:rsimpson@magellan.stanford.edu] Sent: Sunday, January 10, 2010 4:43 PM To: susan.c.kurtik@jpl.nasa.gov; rsimpson@magellan.stanford.edu; sami.w.asmar@jpl.nasa.gov; Riley, Scott L; Bracamonte, Larry H; rsimpson@magellan.stanford.edu Subject: MEX BSR High SNT >1. SNT Increase analysis >Summary by our Goldstone expert: >From: Bracamonte, Larry H >For DOY 234, 255, 256, 260, 284 and 291 the operator set the diode >modulation frequency (MFQ) to "ON" for some of the time. If System >Noise Temperature (SNT) measurement is enabled with the MFQ=ON, the >Downlink Channel will usually report an SNT value of 100 Kelvin since >the diode is not being cycled on and off at a predicted rate. If there >is some level difference detected between the periods when the Downlink >Channel expects the diode to be on compared with the periods the diode >is expected to be off, the Downlink Channel could report an SNT much >greater than 100 Kelvin. When the MFQ is set to "ON" and the SNT is >enabled, the Downlink Channel is not reporting the actual SNT. > >Summary by Scott Riley (lead NOPE): >To summarize what Larry has provided above, with the "MFQ=ON" (rather >than cycling on and off) for the Bi-static configuration (which is what >the Radio Science team requires), the nominal value that would be >recorded for the SNT is 100K. So, from what we can tell based on the >configuration the nominal SNT should be about 100K. However, if there >was a spurious signal, the system could report an SNT that is much >higher than 100K. However, Larry pointed out that if there was truly a >problem there would have been several missions complaining, so this was >more than likely some level being detected (RFI) that caused the SNT >value to Jump. Susan: Thanks for the feedback regarding the high SNT. I have a great deal of respect for Larry; he helped us develop the procedure which we use to do the calibrations for the bistatic radar. I've not met Scott. I don't believe they understand the problem. Note, first, that the issue is with S-LCP. Note also that we use essentially the same calibration procedure on X-RCP, X-LCP, S-RCP, and S-LCP; until 2009/226, they all produced comparable results. The problem is not with the use of the noise diode; we see the high SNT during the pre-cal and post-cal with the ambient load -- as well as during the track with the noise diode. I sent the attached PDF to Jesse at the end of October; it shows the high SNT on S-LCP while we have normal performance on S-RCP during the pre-cal. A Y-factor of 4.2 dB is not normal for S-LCP. These figures were derived from RSR data. We do not use DSN Monitor data because the closed-loop receivers are continually being reconfigured during a bistatic radar experiment so that we can control the noise diodes. There is no interfering signal; we compute spectra which show no narrow band signal within our 25 kHz passband during the pre-cal, the post-cal or the track. If the interference were broad band, I would expect it to affect both RCP and LCP. S-RCP is normal (Y-factor 11.4 dB). We did one experiment using DSS 63 during this string of DSS 14 experiments. It was on 2009/245; DSS 63 uses the same procedure as DSS 14, and DSS 63 was normal on all channels (S-LCP Y-factor was about 11 dB). I can send those plots if they would be of interest. As for other mission complaints, how many use S-LCP regularly? My first guess was that something happened to the DSS 14 S-LCP LNA between 2009/199 (the last normal BSR at 14) and 2009/226. Now that I have completed processing our backlog of BSR data, the S-LCP Mars echo powers I am deriving are suspiciously large starting 2009/226 (except for the DSS 63 experiment on 2009/245). It's possible that the LNA is OK but that large amounts of noise are being added in some downconversion or IF stage before the signal gets to the RSR (or in the RSR itself). Significant noise added after the LNA would cause me to overestimate the echo power. This needs further investigation, with focus on the S-LCP path from LNA all the way to the RSR. Regards, Dick PS: I didn't see Larry on your distribution; but I'm adding him with an address I located from about 5 years ago. I assume Scott can forward if I have it wrong. From rsimpson Tue Jan 19 15:40:27 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o0JNeRS06499; Tue, 19 Jan 2010 15:40:27 -0800 (PST) Date: Tue, 19 Jan 2010 15:40:27 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <201001192340.o0JNeRS06499@magellan.stanford.edu> To: LBracamonte@gdscc.nasa.gov Subject: RE: MEX BSR High SNT Cc: rsimpson, san.c.kurtik@jpl.nasa.gov, terry.anderson@dsn.nasa.gov Content-Length: 1193 Status: O >The reported 7 dB degradation of DSS14 S-HEMT low noise system noise >Y-factor has not been duplicated during testing. It is possible the >problem that caused the 1.4 dB RSR3A degraded performance noted during >testing was worse during the impacted supports. Since the corrective >action was effectively reseating the "CNV" board, recommend using >another channel if possible. Puzzling. The 7 dB degradation on S-LCP has been very consistent starting 2009/226 through the final 2009 experiment on day 291 (including the post-cal on day 234, after the dichroic reflector was extended). The next BSR is scheduled for 2010/041. Scott mentioned the possibility of measuring the Y-factor before then. If those data could also be captured using an RSR, I can look at the results. A simple comparison of dark sky and ambient load would be sufficient; Y-factors of 11 and 5 dB are easy to distinguish. On day 234 the "US 14 MOD 102 A" command was rejected at 09:30:59. It was not reissued again until 14:04:19, when it was successful, as we ended the Mars surface observations. I don't think lack of S-Band signals on 234 was an IF switch problem. Thanks, Larry. From LBracamonte@gdscc.nasa.gov Wed Jan 20 08:21:09 2010 Return-Path: Received: from gex1.gdscc.nasa.gov (gex1.gdscc.nasa.gov [158.154.3.45]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0KGL8N08067 for ; Wed, 20 Jan 2010 08:21:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MEX BSR High SNT Date: Wed, 20 Jan 2010 08:21:27 -0800 Message-ID: In-Reply-To: <201001192340.o0JNeRS06499@magellan.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEX BSR High SNT Thread-Index: AcqZYNZ42h/9KW6KTySA2GwvjabCWwAin6Hg References: <201001192340.o0JNeRS06499@magellan.stanford.edu> From: "Bracamonte, Larry H" To: "Dick Simpson 650-723-3525" Cc: , "Anderson, Terry E" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id o0KGL8N08067 Content-Length: 2300 Status: RO Concur that the dichroic position was the problem for DOY 234. Discrepancy Report G109641 was assigned to document the configuration error. DR G109641 Description: Unable to lock to S-band carrier. Corrective Action: The command to move dichroic mirror was entered incorrectly. The LSOC used MAP display to configure the mirror correctly. Analysis: Jesse Velasco at 2009 267 20:03 Closed to documentation. The NOP section 11.7.2 listed OD US14 CNF MOD 102 A vice US14 MOD 102 A to confirm dichroic reflector in place. The NOP has been updated to direct the station to confirm dichroic reflector is in place. A recording using RSR3A with the DSS14 S-HEMT SLCP path should be completed during the next DSS14 maintenance period. Larry Bracamonte Phone: 760-255-8286 Fax: 760-255-8438 Email: LBracamonte@gdscc.nasa.gov -----Original Message----- From: Dick Simpson 650-723-3525 [mailto:rsimpson@magellan.stanford.edu] Sent: Tuesday, January 19, 2010 3:40 PM To: Bracamonte, Larry H Cc: rsimpson@magellan.stanford.edu; san.c.kurtik@jpl.nasa.gov; Anderson, Terry E Subject: RE: MEX BSR High SNT >The reported 7 dB degradation of DSS14 S-HEMT low noise system noise >Y-factor has not been duplicated during testing. It is possible the >problem that caused the 1.4 dB RSR3A degraded performance noted during >testing was worse during the impacted supports. Since the corrective >action was effectively reseating the "CNV" board, recommend using >another channel if possible. Puzzling. The 7 dB degradation on S-LCP has been very consistent starting 2009/226 through the final 2009 experiment on day 291 (including the post-cal on day 234, after the dichroic reflector was extended). The next BSR is scheduled for 2010/041. Scott mentioned the possibility of measuring the Y-factor before then. If those data could also be captured using an RSR, I can look at the results. A simple comparison of dark sky and ambient load would be sufficient; Y-factors of 11 and 5 dB are easy to distinguish. On day 234 the "US 14 MOD 102 A" command was rejected at 09:30:59. It was not reissued again until 14:04:19, when it was successful, as we ended the Mars surface observations. I don't think lack of S-Band signals on 234 was an IF switch problem. Thanks, Larry. From daniel.s.kahan@jpl.nasa.gov Sun Jan 24 05:38:52 2010 Return-Path: Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0ODcpN04541 for ; Sun, 24 Jan 2010 05:38:52 -0800 (PST) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o0ODcquO004322 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Sun, 24 Jan 2010 05:38:52 -0800 Received: from ALTPHYEMBEVSP30.RES.AD.JPL ([172.16.0.31]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Sun, 24 Jan 2010 05:38:52 -0800 From: "Kahan, Daniel S (332K)" To: "Simpson, Richard A (6520-Affiliate)" , "Goltz, Gene L (332K)" , "Asmar, Sami W (332K)" Date: Sun, 24 Jan 2010 05:36:49 -0800 Subject: RE: DSS-14 SLCP Test Thread-Topic: DSS-14 SLCP Test Thread-Index: Acqb0hOeJIaR/Pu6S++jXG5L7Lpe3wBKDRIh Message-ID: <79D001DEDB0DEC47A247B110F3E86682072E3B4F84@ALTPHYEMBEVSP30.RES.AD.JPL> References: <540.1264212987@magellan> In-Reply-To: <540.1264212987@magellan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: daniel.s.kahan@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id o0ODcpN04541 Content-Length: 2333 Status: RO Dick, Could the problem have to do with the XM satellite radio that we are aware of? (One of the NOPEs mentioned this to me). It has been wreaking havoc on the ADC amplitude readings for a while now, usually after we start tracking the spacecraft. I will forward your message to the proper authorities. Danny ________________________________________ From: Dick Simpson 650-723-3525 [rsimpson@magellan.stanford.edu] Sent: Friday, January 22, 2010 6:16 PM To: Kahan, Daniel S (332K); Goltz, Gene L (332K); Asmar, Sami W (332K); Simpson, Richard A (6520-Affiliate) Subject: Re: DSS-14 SLCP Test >The DSN conducted a test yesterday of the SLCP at DSS-14 in regards to the = >issue that has been in discussion. We recorded 25-KHz RSR data for you to i= >nspect. I have placed two RSR files (both essentially the same data) on rso= >ps2 in your MEX directory. > >I will attach the NMC log separately. Based on my examination of it, the se= >quence of events is such that a calibration was done as follows: > >18:15 start recording with signal injected >18:15 SNT OFF, Ambient Load >18:20 SNT ON, Ambient Load >18:25 SNT ON, Cold Sky >18:30 SNT OFF, Cold Sky >18:35 No signal >18:35 SNT OFF, Ambient Load >18:40 SNT ON, Ambient Load >18:45 SNT ON, Cold Sky >18:50 SNT OFF, Cold Sky >18:55 stop recording Danny: This looks OK if you only consider the test without the injected signal. The level starting 18:35 and the level starting 18:50 differ by about 11 dB, which is what you'd normally expect for S-LCP. It's definitely not 4.7 dB. And the noise diode adds about 1.5 dB when the antenna is looking at cold sky. If this is how DSS 14 comes up for the MEX BSR on 2010/041, our problem with anomalously high SNT should be solved. Please forward good news to people who should know. It turns out this was a good reminder that I've become rusty after no experiments since October. I couldn't get through the firewall to rsops2 and my RSR labeling program didn't work (because the test configuration set some RSR header parameters differently than I expect). I actually figured the labeler would crash because it wouldn't know how to name files collected in 2010; I manually created a label and will have to wait to see how it reacts to 2010 files later. Have a good weekend. Thanks, Dick From rsimpson Sun Jan 24 20:38:58 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o0P4cwx06193; Sun, 24 Jan 2010 20:38:58 -0800 (PST) Date: Sun, 24 Jan 2010 20:38:58 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <201001250438.o0P4cwx06193@magellan.stanford.edu> To: daniel.s.kahan@jpl.nasa.gov Subject: RE: DSS-14 SLCP Test Cc: rsimpson Content-Length: 637 >Could the problem have to do with the XM satellite radio that we are aware of? >(One of the NOPEs mentioned this to me). It has been wreaking havoc on the ADC >amplitude readings for a while now, usually after we start tracking the >spacecraft. I have heard the same thing, and it doesn't make sense. We have had very consistent performance degradation from day 226 to 291. It is present during pre-cal, track, and post-cal and only in S-LCP. There are no unexpected spikes in the spectrum. None of this matches what I would expect from something like XM. I'm willing to be convinced, but there's no evidence so far. From scott.riley@dsn.nasa.gov Wed Jun 30 10:01:12 2010 Return-Path: Received: from DSNOAM-MM.jpl.nasa.gov (dsnoam-mm.jpl.nasa.gov [128.149.207.83]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o5UH1CT28017 for ; Wed, 30 Jun 2010 10:01:12 -0700 (PDT) Received: from dsnoamex1.jpl.nasa.gov (Not Verified[128.149.207.88]) by DSNOAM-MM.jpl.nasa.gov with MailMarshal (v6,7,2,8378) id ; Wed, 30 Jun 2010 10:02:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: MEX BSR High SNT Date: Wed, 30 Jun 2010 10:02:10 -0700 Message-ID: <4CFC28C1247FEB4A982802DEA78252F80102047C@dsnoamex1.jpl.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEX BSR High SNT Thread-Index: AcqZYVfGn3JafNm3RTSUcJ0JHXsW4gABAy3gAAIDuxcAH2QGEAAFtc2wAL5CQBEANgJJkAALAwVgAACyj8AAA6BNgB6ZJsGw From: "Riley, Scott L" To: "Simpson, Richard A" , "Varanasi, Padma" , "Kurtik, Susan C (9020)" , "Varanasi, Padma" , "Asmar, Sami W (332K)" , "Goltz, Gene L (332K)" , "Valencia, Jose" , "Anderson, Terry E" , "Matossian, Harout" , "Metes, Mircea M" , "Pitzer, Donald M" Cc: "Medeiros, Tony M" , "Landon, Arthur J" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id o5UH1CT28017 Content-Length: 4120 Status: RO FYI Team, This was the correspondence on the replacement of the CNV board at GDSCC back in January. --Scott -----Original Message----- From: Bracamonte, Larry H Sent: Monday, January 25, 2010 3:12 PM To: Riley, Scott L Cc: Allen, David; Hofhine, Douglas; Perez, Jose; Massey, Kim; Stroup, Steven; Matossian, Harout; Creech, Ronald E; 'Asmar, Sami W (332K)'; 'Kurtik, Susan C (9200)'; Medeiros, Tony M; Landon, Arthur J; 'Goltz, Gene L (332K)'; !DL-DSN-MPSETD; Anderson, Terry E; 'Kahan, Daniel S (332K)' Subject: RE: MEX BSR High SNT Scott, Yes I believe the "CNV" board in RSR3 degraded the RSR3A performance before the board was replaced and then re-installed. The magnitude of the improvement noted was about 1.4 dB using the RSR Px/No values. The effect on the recorded data was apparently greater. Larry Bracamonte Phone: 760-255-8286 Fax: 760-255-8438 Email: LBracamonte@gdscc.nasa.gov -----Original Message----- From: Riley, Scott L Sent: Monday, January 25, 2010 1:04 PM To: Bracamonte, Larry H Cc: Allen, David; Hofhine, Douglas; Perez, Jose; Massey, Kim; Stroup, Steven; Matossian, Harout; Creech, Ronald E; Asmar, Sami W (332K); Kurtik, Susan C (9200); Medeiros, Tony M; Landon, Arthur J; Goltz, Gene L (332K); !DL-DSN-MPSETD; Anderson, Terry E; Kahan, Daniel S (332K) Subject: RE: MEX BSR High SNT Larry, Wasn't the "CNV' board that was suspected in RSR3? --Scott -----Original Message----- From: Kahan, Daniel S (332K) [mailto:daniel.s.kahan@jpl.nasa.gov] Sent: Monday, January 25, 2010 12:53 PM To: Riley, Scott L; Anderson, Terry E Cc: Allen, David; Hofhine, Douglas; Perez, Jose; Massey, Kim; Stroup, Steven; Matossian, Harout; Creech, Ronald E; Asmar, Sami W (332K); Kurtik, Susan C (9200); Bracamonte, Larry H; Medeiros, Tony M; Landon, Arthur J; Goltz, Gene L (332K); !DL-DSN-MPSETD Subject: RE: MEX BSR High SNT Scott, Assuming we don't need the third RSR for another mission, we can record in parallel to see if there are any differences. However, my impression was that the adjustments that we made had nothing to do with the specific RSR? Just so we're clear, last week's test was done on RSR3. Do we want to consider RSR3 the "backup" and another RSR the "dedicated?" Or vice versa? Danny -----Original Message----- From: Riley, Scott L [mailto:scott.riley@dsn.nasa.gov] Sent: Monday, January 25, 2010 7:31 AM To: Kahan, Daniel S (332K); Anderson, Terry E (9200-Affiliate) Cc: Allen, David; Hofhine, Douglas; Perez, Jose; Massey, Kim; Stroup, Steven; Matossian, Harout (9200-Affiliate); Creech, Ronald E (ronald.creech@dsn.nasa.gov); Asmar, Sami W (332K); Kurtik, Susan C (9200); Bracamonte, Larry H; Medeiros, Tony M; Landon, Arthur J (9200-Affiliate); Goltz, Gene L (332K); !DL-DSN-MPSETD Subject: RE: MEX BSR High SNT Thanks Danny, And many thanks to the GDSCC team for taking the time and effort to isolate and correct this issue. Danny, can we use the RSR that was causing the problem in a Backup posture for the upcoming activities and compare it to the dedicated one? Thanks everyone, --Scott -----Original Message----- From: Kahan, Daniel S (332K) [mailto:daniel.s.kahan@jpl.nasa.gov] Sent: Sunday, January 24, 2010 5:41 AM To: Riley, Scott L; Anderson, Terry E Cc: Allen, David; Hofhine, Douglas; Perez, Jose; Massey, Kim; Stroup, Steven; Matossian, Harout; Creech, Ronald E; Asmar, Sami W (332K); Kurtik, Susan C (9200); Bracamonte, Larry H; Medeiros, Tony M; Landon, Arthur J; Goltz, Gene L (332K); !DL-DSN-MPSETD Subject: RE: MEX BSR High SNT Scott and all, Dick Simpson analyzed the data from the test last week. Please see his message below: Danny: This looks OK if you only consider the test without the injected signal. The level starting 18:35 and the level starting 18:50 differ by about 11 dB, which is what you'd normally expect for S-LCP. It's definitely not 4.7 dB. And the noise diode adds about 1.5 dB when the antenna is looking at cold sky. If this is how DSS 14 comes up for the MEX BSR on 2010/041, our problem with anomalously high SNT should be solved. Please forward good news to people who should know.