SSOC TOBAN REPORT FOR WEEK 26 (27 June to 4 July 1994) SSOC: H. Hudson and T. Kosugi KSC: J. Sato and S. Kawashima 1. SOLAR ACTIVITY --------------------------------------------- Solar activity was extremely low at the beginning of the week, but picked up towards the end. A Bearalert on 30-Jun for M-class flares was rewarded by an M2.5 a few hours later. This event was probably detected well by Yohkoh, but the data are in a DSN dump (now in Sirius but not yet reformatted). The active region, NOAA 7742, has shown flux emergence and many small events. 2. STANDARD OPERATIONS ---------------------------------------- 2.1 SXT table uploads 27-Jun 940627 P4 ARS2 DKCAL 28-Jun 940628 P2 ARS2 STD+LONG 940628 P3 ARS2 STD+LONG 30-Jun 940701 P2 ARS1 STD 2-Jul 940702 P2 ARS1 STD 2.2 STT timer set was done on Tuesday, 28-Jun, and will be done again on Monday, 4-July. The tohbans for week may need to do another setting. 3. SPECIAL OPERATIONS ---------------------------------------- 27-Jun HXT calibration 28-Jun S Offpoint 8 arc min HXT calibration 30-Jun HXT gain adjustment/calibration 1-Jul BCS error recovery BCS stim calibration 4. ERRORS AND PROBLEMS ---------------------------------------- 4.1 Klystrons at KSC A problem was found with the command transmitter during preparations for the first ASCA pass on 1 July. The output transmission power drastically decreased to a level more than a factor of ten below spec. The contractor (NEC) guesses that the klystron may have deteriorated. A detailed examination, and maybe a replacement, will take place Wednesday (6-July) starting at about 1000 JST. It will take about 8 hours and therefore may impact Yohkoh operations that evening. The OP for the previous day will need to take this into account, covering until the 5th pass on that day. 4.2 20-m antenna at KSC There was a problem with the 20-m antenna mechanisms on 29-Jun that threatened operations. On the second ASCA pass (0717 JST) the 20-m drive hung up. It was restored to operation by noon. The cause of the trouble was deterioration of a cooling fan for one of the drive motors; due to this problem a thermal relay for the drive motor tripped. We need replacement of these cooling fans according to the report from MELCO. 4.3 OP_FIRST_GUESS antenna-switch problem The KSC tohbans spotted an incorrect Yohkoh antenna choice in the draft OP for the weekend. Jim Lemen was notified of the problem. He found a bug that would cause this problem with a very low occurrence frequency, and has now fixed it. 4.4 Flare11 .mailrc file An unknown person "clobbered" the .mailrc file in flare11. This contains important aliases used in operations. VISITORS TO B-TOH ARE ENCOURAGED TO LOG IN PROPERLY AND IN ANY CASE NOT TO USE THE YOHKOH ACCOUNT FOR CASUAL THINGS NOT RELATED TO OPERATIONS. That's what our marvelous setup in D-toh is for. 4.5 ISAS network problems There were several network problems, including a complete failure of the system to transfer the large files needed for the archive-level reformatting. The smaller files used for KSC dumps went through OK. We requested help on this from Matsukata-san, the ISAS network manager, and from Shutoh-san, whose program SRSGET was disconnecting. At present we do not understand the cause of the problem, but Freeland-san got the system going by changing the disk mount setup on flare1. It may have been that the earlier mount system was marginal for this application, and that the system revisions involved in adding the Sparc 10's caused the trouble. 5. DSN COMMUNICATIONS ------------------------------------------ 5.1 DSN schedule delivery 5.2 Re-transmission requests There was considerable e-mail communication with DSN regarding the problems we have had with reading playbacks (re-sends of "broken" data). This correspondence is a little confusing. Our understanding is that there are two ways of generating the retransmission files, one of which causes problems for Yohkoh but (surprisingly) both of which are OK for ASCA. An e-mail message from Wendell Keller is appended below. The only re-transmission request we made this week (DOY 171) was re-sent twice, and according to Katano_san the second try was satisfactory. At the time of writing we do not know specifically how to word re-transmission requests to be sure that we get readable data, but it is clear that DSN personnel are aware of the situation. 5.3 RASM acronym competition This week's top entry is "Really Awkward System for Modems" 6. YOHKOH/ASCA PASS CONFLICTS --------------------------------- One KSC pass was lost during Week 27 because of ASCA conflict. Week 28 also has an ASCA conflict (last pass on 4 July) but thus far there are no DSN conflicts. 7. Holiday Schedule --------------------------------- The Yohkoh holiday schedule has been set through the beginning of September in such a way as to minimize the ASCA conflicts, but within our Sunday-holiday policy. 8. HIKITSUGI ITEMS --------------------------------- 8.1 Tobans for week 27 SSOC: Akioka/Fujiki KSC: Kawashima/Watanabe_H 8.2 Yohkoh/ASCA pass conflicts At present, it is SSOC toban's job to negotiate with ASCA people for telemetry conflict resolution. There have been regular tohban-level meetings each Friday at 2:00 pm, including Ito, Zylstra, and Lemen, to work out the problems. 8.3 Katazuke Please delete all personal files that have accumulated in the yohkoh directories on flare11 and flare1. One can get a list of them by doing flare11% ls -lt | more for example. 8.4 New software Katano_san (brilliant NEC software engineer) has made new software that will replace ATTLOG. It will record both real-time offpoints and OP offpoints. She will also run this software. The tohbans should coordinate on this and run ATTLOG if necessary this week. --------------------------------- --------------------------------- Appendix: Copy of e-mail to and from Wendell Keller Date: 6/29/94 5:31 PM Dear Wendell: I called up the real-time operations today to ask about a problem that Yohkoh has apparently had with some re-transmissions. Could you please confirm my present understanding of this situation? This is that the re-transmissions come from the original analog tapes at the individual stations, and that there are two methods for digitizing them. Our system gets confused with the TPA (?) system, but can handle the PDF system output. Thus we should always request the latter. Yoshi Ogawara, our project manager, just told me that ASCA, which should have an identical system here at ISAS, can in fact use both kinds of playbacks, which sounds mysterious to me. Thanks Hugh Hudson (Yohkoh tohban this week) Dear Hugh, 6-29 We have just completed a 5 day NOWG with NASDA, and this afternoon, had a meeting with the Data Chief and the supervisor of the Network Data Processing Area (NDPA) concerning the problems ISAS is reporting with play backs. First, to answer your question-re transmissions do not originate from analog tape unless specifically requested. I will explain our telemetry processing/replay procedures in use. The Data Chief compares the start and end dump times as listed on the TRAKON's Log, with the start and end data times from the IDR gap summary for each pass. If these times do not match, the Data Chief obtains another playback of the data from the SPC, with an analog tape playback being the last resort. If TGC problems occur, (which are documented in discrepancy reports), they require data to be recovered from an analog tape. (Interruptions of the RF signal, such as late AOS can not be recovered from analog tape). The TGCs have two channels for processing telemetry, so both telemetry channels of the TGC process telemetry data, and both channels are recorded on digital tape at the SCP. Each 26m SCP tape records both ASCA and YOHKOH data for a 24 hour period. The SCP tape is then closed, and available for playback from the SPC to NDPA at JPL. The TGC channel with the largest number of frames is selected for the playback. The Data Chief at NDPA records an Intermediate Data Record (IDR), which is subsequently used for playing the data to ISAS via the 56kb using X.25 protocol. When a retransmission request is received, The existing IDR tape, if available is used for the retransmission to ISAS. If the data is over 14 days old, the IDR tape will not be available, and a replay from the SCP tape is obtained. When an analog tape replay is requested, the analog tape must be played back through the PDF in order to provide the correct earth-receive time into the block, (which as I understand it, is necessary to process the data). A question we have concerning the playbacks is stated below: 1. Can the playback request be correlated to a specific earth-receive- time at the station? If so, we could determine whether the data was available on tape, know when it wasn't, and also know we needed to look at the analog tape for it. SPECIAL NOTE: Please note that the analog tapes at DSS 46 will not be available after August 15th due to budget cuts. Analog tapes at Goldstone and Madrid will also probably be phased out soon after that date. I hope this clears things up. If there are any other questions, please don't hesitate to ask. Best Regards, Wendell Keller End of report