[amsat-bb] Re: FW: AMSAT-BB Digest, Vol 4, Issue 401

[Rocky Jones]

Frank

" This e-mail is filled with so many inaccuracies
> and wrong statements that it would be a disservice to the amateur community
> to go through this and challenge each of your statements.  "

so what was the purpose of the six additional paragraphs?

Question...Is suitsat going to have a new name?

Robert WB5MZO

> From: ka3hdo at comcast.net
> To: amsat-bb at amsat.org
> Date: Sat, 15 Aug 2009 21:57:59 -0400
> Subject: [amsat-bb]  FW: AMSAT-BB Digest, Vol 4, Issue 401
> 
> Miles,
> 
> I find it really sad that you have stooped this low.....character
> assassination and the like.  This e-mail is filled with so many inaccuracies
> and wrong statements that it would be a disservice to the amateur community
> to go through this and challenge each of your statements.  
> 
> While I am no longer part of the ARISS team, I think it would be best for me
> to respond to this e-mail as I think some clarifications are worthy of a
> response.  And given the fact that I led the ARISS team for 13 years.
> 
> Your main gripe was that you were not invited to the ARISS meeting at ESA
> Estec a few months ago.  It should be noted that AMSAT did not make this
> final decision.  Specifically, it was your (Miles) actions that caused you
> to be not invited.  Not some  "closed" organization as you (Miles)
> stipulate.  The crux of the issue is that if one disregards verbal or
> written direction from space agencies and, as a result, you violate space
> agency policy or company/agency proprietary rules, then a significant
> element of distrust is built up.  ARISS cannot let this happen.  And Miles,
> through your actions, you did this.  And as a result, you did this to
> yourself.
> 
> Let me also be clear that MAREX as a team was not singled out.  Only Miles.
> So if MAREX had thoughts or proposals, they were and are welcome to share
> them with the ARISS team.  And, if there are other members of MAREX, besides
> Miles, that wanted to attend future meetings, I would expect that they
> probably would be allowed to attend.  As long as they abide by the space
> agency rules.  (But remember, I don't make those decisions)
> 
> ARISS is an international working group consisting of National Amateur Radio
> Societies, AMSAT organizations and the international space agencies from the
> 5 ISS regions (Europe, Japan, Russia, Canada and the USA).  This working
> group works hand-in-hand to develop and operate the amateur radio system on
> ISS.  ARISS cannot do this without the space agencies and the crew on-board.
> ARISS has and continues to do its best to be as transparent (open) as
> possible.  International meetings are open to the public, as long as an
> element of trust is not violated.  While the ARISS model is not perfect,
> nothing is.  But I must say that the international participation and support
> that comes from the ARISS team is some of the best I have ever seen
> anywhere.  To say that ARISS is a failure is ludicrous.
> 
> It is my personal opinion that the national radio society model (e.g. in the
> US ARRL and AMSAT) is the right model for ARISS.  It has worked well and
> provides an outstanding educational outreach program that gives students and
> communities a very positive view of ham radio.  ARISS has not excluded
> universities from participating.  For example, the Kursk University in
> Russia is currently building an experiment for SuitSat-2.  The Santa Rosa
> Junior College in the US is an ARISS telebridge station.  Students at the
> College of New Jersey in the US participated in the testing of the SuitSat-2
> SDX.  And the Wroclaw University of Technology in Poland built the L/S band
> ARISS antennas that are installed on the Columbus module.  
> 
> In summary, I think we should stop the whining.  And recognize that we need
> to work hand-in-glove with the international space agencies if we want to
> sustain a ham radio program on human spaceflight vehicles.  This may mean
> that our pet project might not fly now (or ever).  That there will be times
> when the crew does not get on the ham radio.  And that there will be give
> and take within the international ARISS and international space agency team
> on how hardware gets developed, who develops it and when it gets tested,
> repaired or operated.
> 
> With sincere interest in ARISS Program Success,
> 
> Frank H. Bauer, KA3HDO
> 
> 
> --------------------------------------------------
> Message: 9
> Date: Sat, 15 Aug 2009 10:20:38 -0700 (PDT)
> From: MM <ka1rrw at yahoo.com>
> Subject: [amsat-bb]  Lets Fix ISS, Replace ARISS
> To: amsat-bb at amsat.org
> Message-ID: <394473.2938.qm at web56401.mail.re3.yahoo.com>
> Content-Type: text/plain; charset=utf-8
> 
> Marex 
> 
> Miles Mann WF1F
> 
> Marex
> 
> wf1f at 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-bb at amsat.org. Opinions expressed are those of the author.
> Not an AMSAT member? Join now to support the amateur satellite program!
> http://amsat.org/mailman/listinfo/amsat-bb
> 
> 
> End of AMSAT-BB Digest, Vol 4, Issue 401
> ****************************************
> 
> _______________________________________________
> Sent via AMSAT-BB at 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

_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.windowslive.com/Desktop/PhotoGallery