Miles. well done. I suspect that you have hit a brick wall...but I concur in everything you wrote.
Having said that. ISS and human spaceflight in general (at least in the US) is on the verge of a very big shake up...and that might shake the ham equation as well. Robert Oler WB5MZO > Date: Sat, 15 Aug 2009 10:20:38 -0700 > From: ka1...@yahoo.com > To: amsat-bb@amsat.org > Subject: [amsat-bb] Lets Fix ISS, Replace ARISS > > Marex > > Miles Mann WF1F > > Marex > > w...@marexmg.org > > > > August 25, 2009 > > Dear ARISS supporters: > > I am writing to you because of the extremely poor track record that ARISS has > accumulated over the past 12 years regarding ISS hardware projects. > > The only way to correct the problem and fix the Amateur Radio educational > program is to completely reorganization the current ARISS hardware structure. > > Under the new ARISS Closed Door policy, only selected members from AMSAT-NA > are allowed to participate. > > This new policy has turned the once open ARISS into a closed door Monopoly > controlled by the AMSAT Corporation. > > Based on the current actions of ARISS and their very poor performance with > in-flight hardware I would like to propose a complete reorganization of the > ARISS hardware process. > > Please review the enclosed information. > > I look forward to discussing the proposal with you are your earliest > opportunity. > > Sincerely > > G. Miles Mann > > > > > > Memo from ARISS April 2009 > > From Gaston Bertels ARISS Chairman > > Hi Miles, > > By decision of the ARISS Board, participation to ARISS-i meetings is limited > to delegates from the Member Societies and observers nominated by these > societies. > > USA member societies are the ARRL and AMSAT NA. > > Only these societies can nominate participants to the ARISS-i meetings. > > Best regards > > 73 > > Gaston Bertels, ON4WF > > ARISS Chairman > > > > > > > > > > > > ARISS Reorganization Proposal > > By Miles Mann > > June 17, 2009 > > Rev 1.01 > > > > What is ARISS? > > The goal of ARISS was to create an organization to select, control and > coordinate Amateur Radio projects designed for the International Space > Station (ISS). > > The ARISS program would then assist the 16 countries (Russia, Canada, Japan, > Brazil, USA, member nations of ESA, Belgium, Denmark, France, Germany, Italy, > The Netherlands, Norway, Spain, Sweden, Switzerland, and the United Kingdom), > which are supporting the ISS to help choose the best educational Amateur > Radio projects for ISS. > > Each county would have delegate-voting privileges on ARISS and project > selection activities. > > > > Summary: > > When Dave Larsen and Miles Mann (MAREX) helped form ARISS in August 1996, one > of our goals was to keep Space open for the public and not turn the ISS, into > a monopoly controlled by the AMSAT Corporation. > > We were partially successful. Unfortunately most of the ARISS voting > delegation came from AMSAT Corporation representatives from different > counties and a few other radio clubs. The newly formed ARISS agreed to allow > competing clubs to submit proposals. The MAREX team helped create ARISS, > however since the majority of people present were from the AMSAT Corporation, > MAREX was not allowed to have any voting privileges. > > Prior to 2009, ARISS would say that its meetings were open to the public and > other clubs were welcome to observer. In 2009 ARISS changed its open door > policy to a closed-door policy. The public is no longer allowed to attend any > of the meetings. > > Now, only selected members of the AMSAT Corporation are allowed to present > Amateur radio project proposals to ARISS for International Space Station. > > The AMSAT Corporation has full control over the voting and the hardware > selection process, thus creating a monopoly on the International Space > station for Amateur Radio projects. > > > > ARISS Reorganization Proposal: > > There are two main reasons to reorganize the ARISS delegate voting structure. > > 1) The AMSAT Corporation has a monopolistic control over ARISS and has > routinely blocked competitive Educational Amateur radio projects from being > submitted. The new closed-door policy and "Selected AMSAT Members only" > policy are part of the struggling AMSAT Corporations attempt to make the > International Space Station their private Space Station monopoly. > > > > The actions of the AMSAT Corporation remind me of a fictional movie Quote > "Star Wars, A New Hope" Princess Leia, says to Governor Wilhuff Tarkin: > > "The more you tighten your grip, the more star systems will slip through your > fingers" > > 2) Over the past 12 years AMSAT Corporation has demonstrated its inability to > Select, Manage and Maintain Educational Amateur Radio hardware projects for > the International Space Station. The hardware track record of the AMSAT > Corporation control over ARISS projects on ISS has been very poor. > > In a separate document I will go over the hardware failures and the success > we have had in the ARISS project. You will clearly see a pattern of extremely > poor hardware management, including: > > Poor project selection (even when there is ample evidence to reject a > project, the AMSAT Corporation would approve a project) > Inability to maintain projects in flight. When problems were discovered > in-flight, the AMSAT Corporation would either deny the problem existed or > take 3 or 4 plus years to correct the problem. > Failure to provide NASA and ESA valid project status information. The AMSAT > Corporation would routinely deny there are problems with equipment, even when > ISS crewmembers in-flight reported the problems with the ARISS projects. > AMSAT Corporations refusal to perform basic compatibly and usability testing > on projects has led to some embarrassing failures. The lack of testing has > been a reoccurring team throughout the ARISS projects. > > > Reorganization Solution: > > Change the current voting delegate structure from an AMSAT Corporation > controlled formation to a new structure in which corporations do not control > the Hardware project selection and voting. The best way to manage ARISS > fairly is to select representatives from Universities from around the wold to > take over the delegate voting positions in ARISS hardware projects. > > What I proposed is that representative from 16+ ISS countries each select two > Universities to act as voting ARISS delegates. The new University delegates > would take the place of the existing ARISS delegates. > > The supporting corporations would still be welcome to participate in ARISS > projects, however the corporations would not have Voting rights. > > I also envision that most of the existing duties current performed by the > existing ARISS volunteers wold still continue with the same volunteers and > supporting agencies. The majority of changes will be focused on the > University providing an independent view on which projects make the best > sense. > > The ARISS team claims to provide educational opportunities for the world. > However during the 12 years of ARISS existence, no school or university has > ever built a project for ARISS. The new University Delegate plan would now > open the doors for Universities and other schools to participate in future > ARISS projects. > > Note: the Military funded PC-Sat-2 project by the US Naval Academy may have > had some student involvement. > > > > Who should choose the University Delegates? > > The Space Agency representatives from each supporting ISS nation will be > asked to contact qualifying universities in their countries. Our goal is to > have two universities, with educational programs related to RF technologies > or Space exploration / satellite programs participate as delegates for ARISS. > > The universities will be asked to participate in the ARISS program as a > voting delegate for 4-year terms, with the option to renew. > > > > University Delegate responsibilities: > > The responsibilities of the university delegates will be similar to the > existing ARISS tasks, including: > > Hardware Guild Lines > Project Selection > Hardware meetings and conferences > Work with ESA, NASA and other agencies for the proper approvals and > additional guidelines. > In-flight Project Management > Existing ARISS supporting corporations: > > The existing corporations and clubs such as, ARRL, AMSAT, IARU, MAREX and > others will still be allowed to act as technical consultants and manage > different aspects of ARISS. However these corporations will not have voting > privileges in the hardware selection process. > > > > Additional Benefits: > > TBD > > > > > > > > This section contains a brief over view of example of common ARISS/AMSAT > Corporation failures. > > Poor project selection: > > When ample evidence is presented to ARISS to reject a hardware project, the > ARISS team will still peruse projects that have little benefit for the > Amateur Radio community based on the amount of effort required to fly a > project to ISS. > > Toss-Satellites: > > Toss-Satellites are usually small projects which are literally tossed out the > hatch of the Space Station. Several of these projects were successfully > launched from the Space Station Mir during its 15-year flight. > Toss-Satellites will only run for a few months. Due to the orbit of ISS/Mir > the orbit decay will cause these satellites to re-enter the earth > astmothsphere in 6-18 months. > > With ISS scheduled to be retired in 2015, it is very important for ARISS to > select projects that have a short development time and a great return on the > effort. > > Early on during the ISS project, Frank Bauer (ARISS Chairman and VP of AMSAT > Corporation) said he did not want to waste our valuable resources on building > Toss-Satellites. The MAREX team supported Frank Bauer’s position on > Toss-Satellites. A few years later Frank Bauer and ARISS approved the > Suit-Sat1 Toss-Satellite project. > > The Suit-Sat1 project incorporated a "Expired" spacesuit that was scheduled > to be disposed of in an incinerating Progress module. Instead, the spacesuit > was stuffed with an Amateur Radio beacon and released as a free flying > project. > > The original plan called for the "off-the-shelf-hardware" to be partially > pressurized inside the spacesuit. At the last minute the plans changed and > the equipment was exposed to the full vacuum of space. The transmitter for > the project failed and only a handful of stations were able to hear its > extremely weak signal. > > > > The project was partially successful in that it generated worldwide attention > to ISS and Amateur Radio. > > The Suit-Sat1 version of the project used a combination of existing ARISS > hardware and "off-the-shelf-hardware". The project was completed in a > relatively short periods of time (less than 2 years) primary because it used > mostly existing hardware. The Suit-Sat1 project did consume resources that > could have been used for longer duration projects. > > In 2006, AMSAT Corporation director and ARISS Hardware Manager Lou McFadin > proposed building another project called Suit-Sat2. For this project, rather > than using affordable and easy to deliver "off-the-Shelf" hardware, McFadin > decided to custom build a new transceiver from scratch, using new technology > called "Software Defined Radio". > > The Suit-Sat2 project required over 4 years to develop and will not be ready > for flight until 2010. The Suit-Sat2 project will have a flight life > expectancy of 4-12 months. > > The effort placed into Suit-Sat2 has caused other long term projects to be > ignored. > > > Summary: > > The Suit-Sat1 transmitter failed immediately. > Design called for a pressurized suit, was changed to full vacuum, without any > testing. > AMAST Corporation is continuing to push for more short duration projects. > Longer duration projects are being ignored > > > University Charter proposal changes: > > Under the new ARISS Reorganization Charter, I propose that we cancel all Toss > Satellite projects for the duration of the remaining ISS mission and focus > our attention on longer duration projects that reach more users. > > > > Inability to Maintain projects in flight > > Kenwood TM-D700 Project: > > The Kenwood TM-D700 Transceiver, is a very good product. It is unique it that > is has a built in Data modem and mailbox. The downside to this transceiver is > that it gives the users too much control over the "User Editable Software". > It is possible to modify the software in a way that makes the transceiver too > difficult to operate, and that is exactly what happened on this ARISS project. > > The MAREX team encouraged the AMSAT Corporation to keep the software setup > simple. The MAREX team had used a similar transceiver on Mir and quickly > discovered the Mir cosmonauts were easily confused by the Kenwood PM buttons > (a PM button is a Function button that have the ability to reboot the radio > into a completely new configuration). > > For the sake of brevity, the software complexity failed in many ways, I will > highlight one of the significant failures caused by the complex "User > Editable Software" TM-D700 software. > > The first thing we noticed in December 2003 when the Kenwood TM-700 was > activated from the International Space Station, was that the Packet Mailbox > was practically unusable. Only a very experienced operator, with thousands of > watts of power could access the TM-D700 mailbox. The Data delays caused by > the "User Editable Software" reduced the Mailbox data throughput from 300 > bits per second to less than 50 bits per second (See Data Test note #1). Even > very experienced Satellite packet mailbox users had extreme difficulty access > the TM-D700 mailbox. By comparison, entry level users could easily access the > Mailbox that MAREX installed on Mir. > > ARISS was immediately notified of the problem, however ARISS did not put any > effort into analyzing or correcting the problem. The MAREX team researched > the problem independently of ARISS and discovered that stock terrestrial > versions of the TM-700 had a working Packet Mailbox. The MAREX team soon > discovered the problem was caused by the Criss-Cross software configured that > ARISS had used on the ISS version of the TM-D700. It took MAREX 4 years of > actively lobbying ARISS to fix the problem. > > > > In the spring of 2008 (4+ years after the problem was first discovered) the > ARISS team finally had a new version of software that appeared to work. The > MAREX team tested a subset of this software that was manually configured on > board ISS. The TM-D700 Mailbox began to work for the first time 4 years, with > a normal data throughput. Unfortunately, due to a lack of coordination, a > Replacement TM-D700 was sent to ISS in the summer of 2008. The Replacement > TM-D700 was not loaded with the new software and we are back where we were in > December 2003, running the bad software. > > As of spring 2009 the working "User Editable Software" software has NOT been > loaded on to the ISS version of the TM-D700. The packet mailbox is still > broken on ISS TM-D700. > > Summary: > > The ARISS / AMSAT Corporation never performed any type of functionality > testing of the TM-D700 project before flight. > The ARISS team accepted the project from Bob Brurunga team at face value and > never attempted to verify if the project meet the original operational goals. > The ARISS team took no action to research or fix the problem. After 5 years > of flight, the easily fixable mailbox feature is still broken on ISS. > University Charter proposal changes: > > Under the new ARISS Reorganization Charter, I propose that the university > form a monitoring team to periodically review the status of all Amateur Radio > projects on board ISS and other satellites sharing the same frequencies. The > Review team will provide the NASA and ESA representatives the status of the > On board projects. These reports will include the health of the projects and > what adjustments if any may be required for the safe operation of the > equipment. > > It is normal for projects to require simple periodic maintenance to ensure > proper operation. The Amateur Radio projects are often used for dedicated > School two-way radio links. It would be a simple procedure to have a basic > safety check worked into each school schedule to verify basic aspects of the > Amateur Radio project being used. > > If at any time an Amateur Radio project on ISS appears to be unstable or > possibly on the verge of an unsafe condition, the Review team will notify > NASA and ESA immediately and request the project be shutdown until it can be > reevaluated for safety. > > > > > > > > Failure to provide NASA and ESA valid project status information > > The AMSAT Corporation would routinely deny there are problems with equipment, > even when ISS crewmembers in-flight reported the problems with the ARISS > projects. > > One example, Kenwood TM-D700 Fan. > > The TM-D700 transceiver has a built in Cooling Fan that operates when the > transmitter is active. None of us really paid much attention to the cooling > fan, nor did anyone bother to research the Duty cycle of the fan or its life > span. Instead we did focus on trying to keep the radio cool by not using the > High power mode and "Hard Wiring" the radio so that it would never > transmitter with more than 25 watts, (the terrestrial of the TM-D700 version > is capable of operating at 45 watts transmitter output). > > When the packet Radio options were being discussed, one of the features of > packet is called the Beacon Mode. With this option the packet station would > send out a short 1-2 second bust of data every few minutes. > > Example: > > RS0ISS>CQ [07/21/02 05:19:44]: <<UI>>:ARISS - INNTERNATIONAL SPACE STATION > > The purpose of the beacon is to signal stations on Earth that the ISS packet > station is in range of their location. Normally the window of access > opportunity to ISS is a small 10-minute window. By setting the beacon > correctly we could ensue that most stations would hear the beacon at least > once during their access window. If the beacon were set too frequently, it > would waist power and increase the heat load on the transmitter. > > The MAREX team requested a beacon set for 3-4 minutes at a power setting of 5 > watts. ARISS wanted a beacon set for 2 minutes at 10 watts transmitter power. > ARISS got their way. The beacon option may seem trivial, however it did have > a big effect on the status of the cooling fan. > > No one knew at that time, how the fan worked and what controlled the fans > On/Off cycle. > > The way it works, is when the transmitter is ON, the Fan is ON. When the > transmitter turns OFF, a timer is set and the fan keeps running for 2 more > minutes after the transmitter turns OFF. > > > > Had we known this early, it would have influenced the beacon decision. Since > the beacon was set to Broadcast every two minutes. And the Cooling fan would > run for 2 minutes after the transmitter stopped, it meant that the fan was > running continuously 24 hours a day 7 days a week, whenever the TM-D700 was > turned on. > > The Packet software was designed to be on at all times (except during > Repeater mode). Even when the radio was in Voice mode, the packet system was > still running on a different pair of frequencies. And every two minutes the > packet system would send out another beacon, which kept the cooling fan > running all of the time. > > In August 2006 after 2.5 years of TM-D700 operations in flight, Cosmonaut > Commander Pavel Vinogradov reported the TM-D700 fan did not seem to be > working, "I blow on it, the fan moves and then stops". The day before the > Radio had over heated and locked up due to a problem with the Laptop > transmitter Vox-Box control cable (I will cover Vox-Box control cable in a > separate section). > > I was in the Tele-conference with ARISS when our Energia representative > repeated the conversation he had with Commander Pavel Vinogradov. ARISS > immediately went into denial mode and refused to believe the comments made by > Commander Pavel Vinogradov. The MAREX team requested on several occasions > that ARISS should perform a routine check out of the TM-700 on during one of > the weekly School schedule link days. It would be easy to add a few new > "check list" items to the school schedule checklist to examine the operation > of the fan to verify its status. ARISS flat-out refused to perform any > examination of the fan on the TM-D700. > > Frank Bauer said "I do not want to bring any attention to NASA that we may be > having a problem with fan". > > In August 2007 I talked to ISS crewmember Clayton Anderson on board ISS. I > asked Clayton the question that ARISS had been refusing to ask, "Is the fan > on the TM-D700 working". Clayton responded, "It’s hard to tell, I do not > think the fan is working". > > The statements made by Clayton Anderson and Commander Pavel Vinogradov while > using the TM-D700 on board ISS do not confirm the fan is actually broken, > however there is substantial information present for ARISS to at least start > an investigation. ARISS still refused to investigate the problem. > > Fortunately the Russian engineering team frequently ignores ARISS and decided > that there was sufficient information and decided to send a replacement > TM-D700 and Vox-Box to ISS in 2008. > > > > Summary: > > ARISS / AMSAT Corporation knew there was a possibility the critical cooling > fan on the TM-D700 may have failed and took no action. > ARISS / AMSAT Corporation went out of their way to deny there was any problem > with the suspected cooling fan and continued to allow the transceiver to > operate in unattended modes. > ARISS / AMSAT Corporation refused to investigate the problem which had been > reported by 2 ISS crewmembers in-flight. > University Charter proposal changes: > > Under the new ARISS Reorganization Charter, I propose that the university > assign an independent team to perform a complete safety and functionality > check on every project approved by ARISS for ISS. > > The safety check will included the following: > > Complete review of all technical documentation. > Hardware compatibility testing. Including full End-to-End testing at least a > year before flight. > RFI emissions testing > Human Interface testing (Is the project too complex for the ISS crew to > operate?) > Project delivery schedule (If the project can not be completed in 2-years or > less, it should be canceled) > Hardware Donation to ARISS: > > The Kenwood Company donated (15) Kenwood TM-D700 transceiver to ARISS (around > the year 2000) for the ISS projects. Very early on in the project TM- D700, > MAREX asked Frank Bauer if we could to borrow one of the TM-D700 to evaluate > the performance of the TM-D700 Software, Packet Mail system and over all > functionality. Frank agreed and promised to let MAREX borrow one of the (15) > TM-D700’s. MAREX made the request several time and was always give the same > response, "Yes we will send you one when they are available". > > ARISS never came through with their promise and as a result the TM-D700 never > received the planned crosscheck evaluation of the project as had been > planned. This critical missing Quality Assurance check allowed many > correctable problems to slip through and resulted in an over all very poor > performing and embarrassing project for ARISS and ISS. > > > > > > > > Failure to test projects: > > AMSAT Corporations refusal to perform basic compatibly and usability testing > on projects has led to some embarrassing failures. The lack of testing has > been a reoccurring team throughout the ARISS projects. > > There are many example of the "Failure to test", however I will only > highlight one of the best document cases. > > Slow Scan TV project (SpaceCam1 SSTV): > > The SSTV project consisted for 5 parts: > > SSTV Software, provided by MAREX and Silicon-Pixels > MAREX Delivered the Beta software in 1999. > > Laptop Computer > ARISS took the responsibility of acquiring an approved Laptop to be used for > Amateur Radio project including Packet and Slow Scan TV. ARISS began the > acquisition in 1999 and was finally able to secure a Laptop in 2008. The > Laptop portion of the project only required 9 years to complete. Occasionally > the ISS crew would borrow the "Tourist" Laptops from other projects that > would be used intermittently with Amateur Radio projects. > > Erickson Transceiver > The original SAREX team had some leftover hardware from previous Shuttle > Missions. This hardware was flight qualified for ISS and delivered to ISS in > 2000. > > Vox-Box adapter > An interface needed to be built to allow a Laptop computer to connect to the > Erickson transceiver. AMSAT Corporation directory Lou McFadin (ARISS Hardware > Manager) volunteered to build the interface cable. This cable would be used > for SSTV and other Amateur radio projects. The Vox-Box cable design began in > 1999. > > Antenna System (Team effort from multiple agencies) > A total of 5 cable feed-throughs, with antennas were made available to > Amateur Radio project in the Russian modules. > > > > Lack of End-to-End Testing: > > In the summer of 2000, AMSAT had sufficient hardware and software to start > performing End-to-end testing of the SpaceCam1 project. The ARISS/AMSAT > hardware team had the Antennas, Flight-Laptop (IBM-760XD), SpaceCam1 > software, VOX-Box hardware and the Erickson Transceivers. > > The AMSAT hardware team never performed any End-to-end testing until August > 2003. At a meeting with ARISS in 2003, I was finally given access to the > Erickson hardware for the first time. To my utter amazement, no one on the > AMSAT hardware team had ever connected all of this equipment together prior > to this meeting. The ARISS hardware team had only tested individual parts > separately. > > I discovered numerous problems that should have been discovered years > earlier. The SpaceCam1 project was scheduled to fly to ISS in 2004 and we had > to perform qualifications testing in Moscow in November 2003. > > #1 Erickson Transceiver could not receive SSTV images. > > The first big problem was that the Erickson transceiver was not able to > receive SSTV images. > > The Erickson Transceivers had an audio port connection, which would be > connected to the Laptop through the Vox-Box adapter. The Audio voltage level > coming out of the Erickson connection was approximately 10 volts p-p. The > Laptop microphone input port requires a voltage level of 1-2 volt p-p. > > Since the Erickson was running a voltage much higher than the requirements of > the Laptop, the images displayed on the laptop were completely distorted and > unusable. > > The fix for this problem was never implemented by ARISS and thus the Erickson > Transceiver could not be used for SSTV or any other type of Laptop project. > > > > #2 Vox-Box oscillations > > The Vox-Box is an adapter cable that takes the audio from the Laptop and > sends it to the Radio. The Vox-Box is also responsible to telling the Radio, > when to "Transmit". When the Vox-Box detects audio from the Laptop, it will > then tell the radio to "Transmit". When the audio stops, the Vox-Box will > tell the radio to switch back into receiving mode. > > During the Houston testing in August 2003, we noticed the Vox-Box adapter > would intermittently go into an uncontrolled Oscillation. The Oscillation > would then scramble any images being sent to the radio. > > Eventually a specific hardware configuration was found that seem to reduce > the Oscillations. The Kenwood TM-D700 and the IBM-760XD seemed to be > compatible. The AMSAT team that built the Vox-Box did not perform any > additional circuit modifications to understand or eliminate the Oscillation > problem. > > The two Vox-Box cables used on board ISS are both having problems controlling > the transmitter. When the Laptop signals the Vox-Box to start transmit, the > transmitter is activated correctly. When the Laptop signals the Vox-Box to > Stop transmitter, the Transmitter gets stuck ON. > > #3 Wiener Laptop > > The Wiener Laptop (166 MHz CPU, Windows 2000) was a backup Laptop provided by > the Russian team. This was the first time anyone at ARISS had seen this > Laptop. The Russians said, there was a spare Wiener Laptop on ISS and we were > welcome to use this computer for our Amateur Radio projects. > > The main problem with this computer was also associated with the Audio output > voltage levels. This Laptop was designed to run either low voltage headsets > (1-2 volts p-p) or higher voltage external speakers (15-20 volts p-p). The > Windows 2000 operating Systems was all in Russian and we had very limited > access to a Russian translator to assist with the settings. As a result we > were not able to fully document the changes required to keep the Laptop > running in the low voltage-operating mode. All images transmitted from the > Wiener Laptop while in the default Speaker setting came out scrambled. > > > > Moscow KIS testing November 2003 > > During the months before the trip to Russia, the ARISS and MAREX team linked > up frequently by conference call. One of the goals requested by MAREX was > that we have a pre-test staging day set aside so that we could retest all of > the hardware, before going to the KIS testing facility. The pre-test staging > was very important because of the poor results we had during the August 2003 > Houston testing session. Frank Bauer and the ARISS team agreed and plans were > made to set aside a day to stage all of the hardware before taking the > hardware to the KIS facility. > > Shortly after we arrived in Moscow, Frank Bauer told me that we would not > have a Staging test day and that we wold not have access to the hardware > until the morning of the KIS flight certification testing. A disaster was > looming. > > On the testing day, a good portion of the morning was taken up by going > through the required security processes. When we finally arrived in our > testing office with all of our hardware, we only had 1 hour to unpack and get > ready for the testing, inside the mockup module of the ISS service module. > > All of the problems we had in Houston came back and then some. The first > stumbling block was that we did not have our translator with us. During the > previous 2 days of meetings, we had full access to a qualified translator. > However, in the KIS facility we did not have a translator, which would have > really been useful. > > The Wiener Laptop was installed in the Service module first. Unfortunately > the settings I made to the Wiener Laptop in August 2003 had been changed and > the Laptop was now sending speaker audio out at 20 volts p-p. The high > voltages caused all SSTV images sent from the service module to become > completely scrambled. > > The IBM 760XD and TM-D700 combination in the Office overlooking the Service > module was also having problems sending images to the Service Module. > > Our Back up Kenwood HT with a SSTV microphone (VCH1-Communicator) was out of > service because the battery had not been charged. Fortunately we had the 220 > Volt power cube for the HT, unfortunately the plug pins were too short to > reach inside the Russian AC power outlet or Power strips. > > I went to a group of Russian engineers wearing white jackets and handed them > the Power Cube and a Power Strip and said in English, "Fix". The engineers > took the power cube and power strip and walked a way. A few minutes later > they came back. They had removed the protective cover to the power strip and > taped the Power Cube on to the exposed 220-Volt brass contact bars. The > engineer said in English "No Touch". Wow that was fast and simple Russian > engineering. I now had 1 working SSTV system. Unfortunately I needed two > working SSTV systems. > > I began working on the IBM-760XD in the lab and discovered the Audio levels > were set incorrectly, which was easy to correct. After a few minutes I was > able to send and receive SSTV images to the Backup VCH1-Commander system in > the same lab. I was also able to send Frank Bauer SSTVimages in the Service > module. Frank was still not able to Send images because of the audio level > problems with the Wiener Laptop. > > Frank ordered me into the Service Module to fix the Wiener computer. > Unfortunately, without a Russian translator, I could not easily navigate the > Russian version of Windows 2000 to find the correct audio settings. At one > point, a group of Cosmonauts squeezed into the Service model to see the new > SSTV project. Everyone posed for pictures. One of the cosmonauts looked at > the scrambled SSTV images on the screen and said in English, "Not working?" I > responded in poor Russian "Little Problem", I was very embarrassed. > > Then we got lucky, the battery on the Wiener computer died. We were not > allowed to run the laptops on AC power, they had to run on batteries for > their emission portion of the tests. The dead batter allowed us the blame the > battery for the problems and gave us the opportunity to swap over to the > IBM-760XD and Kenwood TM-D700 configuration. Within a few minutes the working > IBM-760XD was moved from the lab, into the Service Module. Once setup Frank > and I were able to Send and receive good quality SSTV images to and from the > Service Module and we were able to pass the emissions testing. > > Changes to the Vox-Box power source: > > A few weeks after the Moscow certification test, the power source for the > Vox-Box was changed from a 9-Volt battery to be able to receive power > directly from inside the Kenwood TM-D700 transceiver. This modification was > only performed on the TM-D700 in Russia, one of which was flown to ISS in the > fall of 2003. None of the other TM-700 in the USA based ARISS Hardware team > made the same changes or confirmed their functionality. > > When the Vox-Box was used in-flight for SSTV in August 2006, the Vox-Box > would turn ON the transmitter, however the Vox-Box circuit would get stuck > and would not turn the transmitter OFF. > > A new Vox-Box and TM-D700 were flown to ISS in the summer of 2008. When the > SSTV was activated again, the same problem occurred, the transmitter would > get stuck in the ON position. Flight participant Richard Garriott, tried two > different SSTV applications and both had the same problem. ARISS wants to > blame the SpaceCam1 SSTV software, however, since the problem was seen with > two completely different SSTV applications, we can assume that is its not a > software issue. > > The cause of the stuck transmitter is most likely and RF interference on the > DC power source feeding from the TM-D700 transmitter into the Vox-Box. I have > shown a few engineers the schematic for the ARISS Vox-Box and they all ask > the same questions, "Where is the RF bypass filtering, there is none". > Without proper RF bypass circuits, it would be easy for the Vox-Box switch to > get stuck on the ON condition. > > > > Summary: > > Lack of End-to-end testing left us poorly prepared with limited hardware > options. > Canceling of the pre-test Staging resulted in an embarrassing and stressful > testing session. > The Vox-Box Oscillation problem was observed by oscilloscope in Moscow. > Changes to Vox-Box power source were not fully tested and may be the cause of > the two In-flight failures. > > > University Charter proposal changes: > > Under the new ARISS Reorganization Charter, I propose that the university > assign an independent team to perform a complete safety and functionality > check on every project approved by ARISS for ISS. > > The safety check will included the following: > > Complete review of all technical documentation. > Hardware compatibility testing. Including full End-to-End testing at least a > year before flight. > RFI emissions testing > Human Interface testing (Is the project too complex for the ISS crew to > operate?) > Project delivery schedule (If the project can not be completed in 2-years or > less, it should be canceled) > Last minute changes will need to be verified before ARISS will signoff on a > problem. > > > > > > > > _______________________________________________ > Sent via amsat...@amsat.org. Opinions expressed are those of the author. > Not an AMSAT-NA member? Join now to support the amateur satellite program! > Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_sync:082009 _______________________________________________ Sent via amsat...@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
