Marex
Miles Mann WF1F
Marex
[email protected] Aug 15,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.