PDS_VERSION_ID = PDS3 RECORD_TYPE = STREAM DATA_SET_ID = "MEX-M-MRS-1/2/3-EXT2-2101-V1.0" STANDARD_DATA_PRODUCT_ID = ENB PRODUCER_ID = "SUE" PRODUCT_ID = "M00SUE0L1A_ENB_092560738_00.TXT" PRODUCT_CREATION_TIME = 2012-06-28T11:36:50.000 INSTRUMENT_HOST_ID = "MEX" OBJECT = TEXT PUBLICATION_DATE = 2011-03-10 NOTE = "MEX SUE Experimenter Notes" END_OBJECT = TEXT END From mars_ops-bounces@sciops.esa.int Mon Apr 13 06:05:03 2009 Return-Path: Received: from esa-sf1.esa.gmessaging.net (esa-sf1.esa.gmessaging.net [194.51.201.67]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n3DD52C18410 for ; Mon, 13 Apr 2009 06:05:02 -0700 (PDT) Received: from esa-sf1.esa.gmessaging.net (localhost [127.0.0.1]) by localhost.esa.gmessaging.net (Postfix) with SMTP id B4E265B8100 for ; Mon, 13 Apr 2009 15:04:54 +0200 (CEST) Received: from sciops-mailgw.vilspa.esa.int (sciops-mailgw.vilspa.esa.int [193.147.152.105]) by esa-sf1.esa.gmessaging.net (Postfix) with ESMTP id 6F9925B80BB for ; Mon, 13 Apr 2009 15:04:54 +0200 (CEST) Received: from sciwww01.esac.esa.int (sciwww01.esac.esa.int [193.147.152.112]) by sciops-mailgw.vilspa.esa.int (Postfix) with ESMTP id 5CE1711F8ED for ; Mon, 13 Apr 2009 15:05:01 +0200 (CEST) Received: from sciwww01.esac.esa.int (localhost.localdomain [127.0.0.1]) by sciwww01.esac.esa.int (8.13.1/8.13.1) with ESMTP id n3DD4vSC024047 for ; Mon, 13 Apr 2009 15:05:01 +0200 Received: from sciops-mailgw.vilspa.esa.int (sciops-mailgw.vilspa.esa.int [193.147.152.105]) by sciwww01.esac.esa.int (8.13.1/8.13.1) with ESMTP id n3DD4tre024044 for ; Mon, 13 Apr 2009 15:04:55 +0200 Received: by sciops-mailgw.vilspa.esa.int (Postfix) id 9AEE411FAC3; Mon, 13 Apr 2009 15:04:55 +0200 (CEST) Delivered-To: mars_ops@sciops.esa.int Received: from sciops.esac.int (scimail.esac.esa.int [193.147.152.87]) by sciops-mailgw.vilspa.esa.int (Postfix) with ESMTP id 8DB3811F8ED for ; Mon, 13 Apr 2009 15:04:55 +0200 (CEST) Received: from [10.66.180.52] (ssow11.net3.lan [10.66.180.52]) (authenticated bits=0) by sciops.esac.int (8.13.1/8.13.1) with ESMTP id n3DD4t5A001435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Apr 2009 15:04:55 +0200 Message-ID: <49E33878.8000805@sciops.esa.int> Date: Mon, 13 Apr 2009 15:04:56 +0200 From: Jim Volp Organization: Serco User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mars_ops@sciops.esa.int Content-Type: multipart/mixed; boundary="------------090201030206030405080909" Subject: [Mars_ops] [Fwd: [MEXSGS] Mars Express specific requests for pericenter gravity] X-BeenThere: mars_ops@sciops.esa.int X-Mailman-Version: 2.1.5 Precedence: list List-Id: mars_ops.sciops.esa.int List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mars_ops-bounces@sciops.esa.int Errors-To: mars_ops-bounces@sciops.esa.int Content-Length: 7003 Status: RO This is a multi-part message in MIME format. --------------090201030206030405080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI: Date: Mon, 13 Apr 2009 15:04:15 +0200 From: Jim Volp Organization: Serco User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Espinueva, Ruben P" References: <49C8A23F.9060205@sciops.esa.int> In-Reply-To: <49C8A23F.9060205@sciops.esa.int> Content-Type: multipart/mixed; boundary="------------060809090309090700060506" Cc: "Arroyo, Belinda" , Mexsgs@sciops.esa.int, "Thompson, Thomas W" , Stefan Remus , mexmps , "Bell, Julia L" Subject: [MEXSGS] Mars Express specific requests for pericenter gravity X-BeenThere: mexsgs@sciops.esa.int X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mars Express Science Ground Segment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mexsgs-bounces@sciops.esa.int Errors-To: mexsgs-bounces@sciops.esa.int This is a multi-part message in MIME format. --------------060809090309090700060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ruben, Belinda, Tommy, Julia, I hope this message still arrives before you go to the airport in order for you to prepare yourselves (if need be). It is a good practical case that we can discuss further on Wednesday. We would like to request the following specific passes in order to be able to do (very important) pericenter gravity observations: Times quoted are UTC on ground: YR-DoY start end (MEX ref) 09-217 15:22:35 - 16:22:35 (orbit 7173) 09-227/8 23:34:55 - 00:34:55 (orbit 7209) 09-235 03:57:05 - 04:57:05 (orbit 7234) 09-239 04:28:56 - 05:28:56 (orbit 7248) 09-242 08:19:27 - 09:19:27 (orbit 7259) 09-246 08:51:25 - 09:51:25 (orbit 7273) 09-249 12:42:02 - 13:42:02 (orbit 7284) 09-256 17:04:47 - 18:04:47 (orbit 7309) ( Table also attached in ASCII.) Stations that support Radio Science, as you know, are either 70m or HEF. 70m (if possible), has preference given the higher SNR. Station configuration as far as I know should be: X-band up (for last 40 minutes) and S-band & X-band down. Ranging in both S- and X-band. NO telemetry (ref. GRP for ESOC) Probably from your planning point of view only the X-band uplink is of importance. Jim ps Is this the format in which you most effectively can use this information / process this request ? From daniel.s.kahan@jpl.nasa.gov Mon Sep 14 13:49:15 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 n8EKnET18623 for ; Mon, 14 Sep 2009 13:49:14 -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 n8EKmdOQ010138 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Mon, 14 Sep 2009 20:49:13 GMT Received: from ALTPHYEMBEVSP30.RES.AD.JPL ([128.149.137.84]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Mon, 14 Sep 2009 13:49:04 -0700 Content-Type: multipart/mixed; boundary="_000_79D001DEDB0DEC47A247B110F3E86682062DBCD110ALTPHYEMBEVSP_" 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, 14 Sep 2009 13:49:02 -0700 Subject: MEX 2009-256 Bistatic Radar Data Thread-Topic: MEX 2009-256 Bistatic Radar Data Thread-Index: AcnBvc7pAV3j4C4FQRakmyn/J88GbQFv/gNwDF1L9rAAM8xNIAEn3t0gAAqqr7ACtgxCEAV/quiAAWBL5LAEIK+LAAAFPJnA Message-ID: <79D001DEDB0DEC47A247B110F3E86682062DBCD110@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: <79D001DEDB0DEC47A247B110F3E86682062DBCD110@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: 16082 Status: O --_000_79D001DEDB0DEC47A247B110F3E86682062DBCD110ALTPHYEMBEVSP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dick, A MEX Bistatic Radar Experiment on DOY 2009-256 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 = 07:38:00 - stop = 08:50:01 - start = 09:36:59 - stop = 12:15:00 - SFDUs = 55,216 and: - S-band RCP, 1-way - RSR2A3 - 25 kHz, 16 bits - start = - stop = - start = - stop = - Did not play back due to no SRCP signal and: - X-band LCP, 1-way - RSR3B3 - 25 kHz, 16 bits - start = 07:38:00 - stop = 08:50:00 - start = 09:36:59 - stop = 12:15:00 - SFDUs = 55,212 and: - S-band LCP, 1-way - RSR3A3 - 25 kHz, 16 bits - start = 07:38:00 - stop = 08:50:00 - start = 09:36:59 - stop = 12:15:00 - SFDUs = 55,212 plus: - X-band RCP, 1-way - RSR2B4 - 100 kHz, 16 bits - start = 10:00:00 - stop = 11:07:00 - SFDUs = 80,420 and: - S-band RCP, 1-way - RSR2A4 - 100 kHz, 16 bits - start = - stop = - SFDUs = Did not play back due to no SRCP signal and: - X-band LCP, 1-way - RSR3B4 - 100 kHz, 16 bits - start = 10:00:00 - stop = 11:07:00 - SFDUs = 80,420 and: - S-band LCP, 1-way - RSR3A4 - 100 kHz, 16 bits - start = 10:00:00 - stop = 11:07:00 - SFDUs = 80,420 These data should now be available for you to query. - Regards, Gene & Danny From wilson.chen@dsn.nasa.gov Mon Sep 14 09:49:36 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 n8EGnZT17604 for ; Mon, 14 Sep 2009 09:49:35 -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 ; Mon, 14 Sep 2009 09:49:34 -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_01CA355B.561E33B6" Subject: 41 RMDC Radio Science Delivery Date: Mon, 14 Sep 2009 09:49:33 -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/UIADtPmwgAY88RiAAPLpgIADCFpkgAgKgSyABUk9qIADKO0Yg References: To: Cc: "!DL-DSN-RMDC" , Content-Length: 11339 Status: RO This is a multi-part message in MIME format. ------_=_NextPart_001_01CA355B.561E33B6 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/09255O255_14X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09255O255_14S_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09256O256_14X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09257O257_14X_1s.SC041 OSCARX://ftp/ras/sc41/odfs/09257O257_14S_1s.SC041 Regards, Wilson Chen RMDC Analyst Phone: 626-305-6269 Email: wcchen@jftl.jpl.nasa.gov wilson.chen@dsn.nasa.gov From gene.goltz@jpl.nasa.gov Sun Sep 13 05:27:30 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 n8DCRUT16462 for ; Sun, 13 Sep 2009 05:27:30 -0700 (PDT) Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by mail.jpl.nasa.gov (Switch-3.4.1/Switch-3.3.2mp) with ESMTP id n8DCRSRi000727 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO); Sun, 13 Sep 2009 12:27:28 GMT Received: from ggoltz-xp.jpl.nasa.gov (ggoltz-2k.jpl.nasa.gov [137.78.78.47]) by xmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n8DCRQeZ010390; Sun, 13 Sep 2009 05:27:27 -0700 Message-Id: <6.2.5.6.2.20090912231634.02064490@jpl.nasa.gov> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 13 Sep 2009 05:27:26 -0700 To: Dick Simpson 650-723-3525 From: Gene Goltz Subject: MEX 2009-256 BSR Ops Log Cc: Sami Asmar , Daniel.S.Kahan@jpl.nasa.gov, John.C.Klose@jpl.nasa.gov Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_-1697249156==_" X-Source-IP: ggoltz-2k.jpl.nasa.gov [137.78.78.47] X-Source-Sender: gene.goltz@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Content-Length: 98915 Status: RO --=====================_-1697249156==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Dick, Attached please find the operations log for the MEX Bistatic Radar (BSR) experiment that was conducted at DSS-14 on 13 September (DOY 256). Very strong X-band echoes were returned, but the S-band RCP signal was not received at the RSR (DR G-109692) even though there was a signal received at the closed-loop receiver (DTT). - Gene & Danny --=====================_-1697249156==_ Content-Type: application/octet-stream; name="MEX_BSR_20090913.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="MEX_BSR_20090913.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAjAAAAAAAAAAA EAAA/v///wAAAAD+////AAAAAIoAAACLAAAA//////////////////////////////////////// ... From arthur.j.freiley@jpl.nasa.gov Thu Sep 17 07:05:08 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 n8HE58T23506 for ; Thu, 17 Sep 2009 07:05:08 -0700 (PDT) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by mail.jpl.nasa.gov (Switch-3.4.1/Switch-3.3.2mp) with ESMTP id n8HE57bK016836 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Thu, 17 Sep 2009 14:05:07 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.80]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Thu, 17 Sep 2009 07:05:07 -0700 From: "Freiley, Arthur J (333F)" To: "Simpson, Richard A (6520-Affiliate)" Date: Thu, 17 Sep 2009 07:05:05 -0700 Subject: RE: MEX DSN Data Report Thread-Topic: MEX DSN Data Report Thread-Index: Aco3NOzGnND8qkwgSuupwP5/qW89OwAaqR4g Message-ID: <9EA3481ECE810A4194AA235503C4CE11369A57A095@ALTPHYEMBEVSP10.RES.AD.JPL> References: <200909170119.n8H1JTA17632@magellan.stanford.edu> In-Reply-To: <200909170119.n8H1JTA17632@magellan.stanford.edu> 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: arthur.j.freiley@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id n8HE58T23506 Content-Length: 5595 Status: RO Dick, Is it time to review the front-end configurations to ensure all is connected correctly? Art To: arthur.j.freiley@jpl.nasa.gov Subject: RE: MEX DSN Data Report Cc: >Is it time to review the front-end configurations to ensure all is connected correctly? We have been doing a lot of MEX BSRs at DSS 14, and things usually are fine. I think someone disconnected a cable, then forgot to put it back. I'm not sure what we can do to prevent that. We did another experiment this morning, and all was normal. We lost two on the weekend, probably because there was no one on site to trace the cables and make the fix. From mpaetzol@uni-koeln.de Thu Sep 17 01:59:42 2009 Return-Path: Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [134.95.19.53]) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n8H8xfT23104 for ; Thu, 17 Sep 2009 01:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at uni-koeln.de Received: from smtp.uni-koeln.de (milter4.rrz.uni-koeln.de [134.95.19.193]) by smtp-out.rrz.uni-koeln.de (8.13.8/8.13.8) with ESMTP id n8H8xds7003466 for ; Thu, 17 Sep 2009 10:59:40 +0200 X-MSA-SIP: paris.planet.uni-koeln.de [134.95.38.5] Received: from [134.95.38.5] (paris.planet.uni-koeln.de [134.95.38.5]) by smtp.uni-koeln.de (8.13.8/8.13.8) with ESMTP id n8H8xcIn012331 for ; Thu, 17 Sep 2009 10:59:39 +0200 Message-ID: <4AB1FAD2.8080300@uni-koeln.de> Date: Thu, 17 Sep 2009 11:01:06 +0200 From: =?ISO-8859-15?Q?Martin_P=E4tzold?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dick Simpson 650-723-3525 Subject: Re: MEX DSN Data Report References: <200909170119.n8H1JTA17632@magellan.stanford.edu> In-Reply-To: <200909170119.n8H1JTA17632@magellan.stanford.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 134.95.19.53 Content-Length: 4852 Status: RO Dick, I understand that the "Anomalies" section refers to the BSR experiments on DOY 255 and 256. I also understand that S-LCP has been received nominally, so the spacecraft S-band transmitter has been in operation? Best M. From rsimpson Thu Sep 17 08:51:24 2009 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id n8HFpNm29072; Thu, 17 Sep 2009 08:51:23 -0700 (PDT) Date: Thu, 17 Sep 2009 08:51:23 -0700 (PDT) From: Dick Simpson 650-723-3525 Message-Id: <200909171551.n8HFpNm29072@magellan.stanford.edu> To: mpaetzol@uni-koeln.de Subject: Re: MEX DSN Data Report Cc: rsimpson Content-Length: 561 Status: R >so the spacecraft S-band transmitter has been in operation? Yes. There is a clear S-LCP signal, and S-RCP was received with the closed loop system. My guess is that someone disconnected the S-RCP RSR from the antenna for testing and forgot to replace the cable. Swapping in another RSR did not solve the problem, so the cable disconnect was problably somewhere in the IF where it could not be easily repaired by the weekend operations crew. This happens more often than it should. S-RCP was normal on the experiment this morning (260). From jesse.velasco@dsn.nasa.gov Fri Sep 18 14:32:49 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 n8ILWmT15210 for ; Fri, 18 Sep 2009 14:32:49 -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 ; Fri, 18 Sep 2009 14:32:48 -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: MEX DSN BSR Data Report Date: Fri, 18 Sep 2009 14:32:48 -0700 Message-ID: In-Reply-To: <200909102322.n8ANMsx10275@magellan.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEX DSN BSR Data Report Thread-Index: Acoybat4uMUNgxL3R4yGKljyokEQ2AGOWW2Q References: <200909102322.n8ANMsx10275@magellan.stanford.edu> From: "Velasco, Jesse" To: "Dick Simpson 650-723-3525" , "Kahan, Daniel S" , "Goltz, Gene L" Cc: "!DL-DSN-MPSETD" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by magellan.stanford.edu id n8ILWmT15210 Content-Length: 5289 Status: RO Dick, For the BSR supports on DOY 255 and 256 would you say the S-band radio Science data was degraded or a complete outage? I want to want to update the outages on the DRs. Currently we have the outages listed as telemetry. Thanks Jesse From rsimpson Mon Sep 21 12:33:25 2009 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id n8LJXO221467; Mon, 21 Sep 2009 12:33:24 -0700 (PDT) Date: Mon, 21 Sep 2009 12:33:24 -0700 (PDT) From: Dick Simpson 650-723-3525 Message-Id: <200909211933.n8LJXO221467@magellan.stanford.edu> To: jesse.velasco@dsn.nasa.gov Subject: RE: MEX DSN BSR Data Report Cc: ggoltz@mail.jpl.nasa.gov, kahan@mail.jpl.nasa.gov, rsimpson Content-Length: 1486 Status: R >For the BSR supports on DOY 255 and 256 would you say the S-band radio >Science data was degraded or a complete outage? I want to want to update >the outages on the DRs. Currently we have the outages listed as >telemetry. Our primary science objective in MEX BSR is to measure the dielectric constant at S-Band, measure the dielectric constant at X-Band, and then use the two measurements to infer something about how the surface properties change with depth in the material. When you only have one of two polarizations, you can't measure the dielectric constant. When you have only one band, you can't say anything about the depth variations. In practical terms we lost the S-Band science on days 255 and 256, even though we still had one polarization. Because we lost S-Band, we lost the ability to do the depth analysis. S-Band is always weaker and harder to measure than X-Band, so it's not really fair to say we lost 50 percent (or more) of the science. But I think it is fair to say we lost more than 25 percent. I think you, Danny, and Gene have been negotiating so the station can capture some of the X-Band telemtry around the BSRs; and I think that's good so long as the BSR is not impacted. But I don't think we want to say that telemetry was the main casualty here; the reason for having the pass was bistatic radar/radio science, and that's what took the hit. Besides, there's rarely any S-Band telemetry. Good enough? 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 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 fro= m reading the DRs that there were problems with the IF switch to the open l= oop equipment (the IF switch for the closed loop receivers were fine). I w= as not able to find the high noise temperature DRs, so I have asked the NOP= Es to follow up on this issue too. Almost everyone was gone over the holid= ays, so I haven't gotten a response back yet. Thanks for your nice comment= s 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 e= fforts confirmed there was no signal going to the RSR, yet there was a sign= al to the DTT closed loop receiver. Since the closed loop signal is transf= erred 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 signa= l 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 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 yo= u 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 modulat= ion frequency (MFQ) to "ON" for some of the time. If System Noise Temperatu= re (SNT) measurement is enabled with the MFQ=3DON, the Downlink Channel wil= l usually report an SNT value of 100 Kelvin since the diode is not being cy= cled on and off at a predicted rate. If there is some level difference dete= cted 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 s= et to "ON" and the SNT is enabled, the Downlink Channel is not reporting th= e actual SNT. Summary by Scott Riley (lead NOPE): To summarize what Larry has provided above, with the "MFQ=3DON" (rather tha= n cycling on and off) for the Bi-static configuration (which is what the Ra= dio Science team requires), the nominal value that would be recorded for th= e SNT is 100K. So, from what we can tell based on the configuration the nom= inal 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 detect= ed (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 re= placed 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 re= produce the problem Larry's analysis: DR G109692 on DOY 256: Downlink Channel 3 (DC03) reporte= d a stable total power gain control value of about 0.77 volts and that volt= age 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, whe= n microwave switch 12 was in position A, DC03 reported a voltage of 0.83. S= witch 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 lev= el. 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 ha= s tested this UWV switch and verified that when the switch is in the incorr= ect position they receive the exact indications as was seen during the expe= riment, but what they cannot do is get the switch to fail again into that p= osition. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 17:21:11 2010 Return-Path: Received: (from rsimpson@localhost) by magellan.stanford.edu (8.11.7p3+Sun/8.11.7) id o0B1LB109858; Sun, 10 Jan 2010 17:21:11 -0800 (PST) Date: Sun, 10 Jan 2010 17:21:11 -0800 (PST) From: Dick Simpson 650-723-3525 Message-Id: <201001110121.o0B1LB109858@magellan.stanford.edu> To: susan.c.kurtik@jpl.nasa.gov Subject: Re: MEX BSR and GRV DSN Data Cc: rsimpson, sami.w.asmar@jpl.nasa.gov, scott.riley@dsn.nasa.gov Content-Length: 475 Status: RO > 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 S-RCP operation was restored in time for the 17 Sept 2009 BSR. Intermittent switch/connector problems can be difficult to track down. It's sufficient for my purposes to have the signal back. 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: RO >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.