Happy New Year from Delta-Utec

We wish all former YES2 members a productive, healthy and happy 2009!

As described in my previous message, the YES2 legacy continues. A 5 km tether has been wound for an experiment on Progress around 2011 (Baumann institute in Moscow). We are also started a YES2 reflight preparatory study on a Shtil (with Makeev) or perhaps Bion (in co-operation with SSAU). The Acta Actronautica paper with first mission results will be published very soon. The Aerospace America featured a nice summary of the YES2 mission data analysis in its overview of defining moments of 2008 (with a picture of Dimitris working on the satellite).  We have in the mean time also rebuilt the YES2 electronics system and we could reproduce similar behavior as seen in flight, which means that we have identified the likely cause of the failure of OLD electronics  that stopped the deployment control some 2300 s before deployment completed (brace yourself for some technical detail).

Test set-up reproducing flight results. R1 simulates the internal short (15 Ohm) in one of the OBC's interrupt line. This short was present before flight and the signal was made functional by a patch (the transistor) that consumed a too much power for the small DC/DC converter, putting noise on the other RS422 receivers that are meant to feed OLD signals to the OBC.

What seems to have happened  is the following: as both the flight and spare YES2 (commercial) on-board computers showed some anomalies before flight, an electronic patch was added to the flight board as an ad-hoc solution. This patch required a 5V power supply. YES2 had available two 5V power supplies, a small one (1.5W) for the most critical circuits such as pyro firing control and telecommand handling, and a large one (30W) for deployment control and secondary functions. It was decided, for consistency, that the patch was to be powered from the small supply for critical functions. This proved to be a mistake. The patch demanded significant power, and the 1.5W power supply was used close to its maximum limit, increasing noise levels and decreasing voltage. As the temperature of the system increased during the mission by various degrees (in itself fully nominal), the sensitivity of the on-board computer signal input lines to these parameters increased, until the point that the noise itself was generating interrupt signals, at as high as 10 kHz, swamping the actual deployment data. The software filter (correctly) identified the signals on the affected channels as false and rejected all of the interrupts arriving from them (including the swamped good data). As a result, the measurement of length increments effectively stopped at this point. The controller assumed then that deployment had stopped and reduced the brake force. This lead to accelerated overdeployment and an abrupt stop of deployment when the tether was fully deployed. It is unfortunate that this problem could have been easily avoided. The reason that this was not down boils down to the time pressure and the fact that the team at the time the patch was installed (shortly before satellite delivery) was overworked. The budget for building and testing YES2 was released only 9 months before delivery, which put tremendous pressure on the team. Tests were nevertheless performed after installation of the patch to demonstrate good performance, but these tests were done in ambient conditions and did not feature the rise in temperature that was seen in the mission. Alternative ways of preventing the failure would have been: earlier budget release/start of integration test phase to buy time for fundamental solutions, replacing the on-board computer rather than patching it (not possible due to lead time), powering the patch from the 30W supply (simple and effective),  accepting the anomaly (even simpler and ok as the affected function was covered by redundancy), inverting the input signal to the patch (reducing the power consumption greatly with little effect on performance).

Analysis of the data shows that each one of these actions would have led to a proper deployment control till the very end and a nominal Fotino re-entry with a landing site very close to the location of the recovery team (tens of kilometers).

The research so far suggest other improvements that should be made for a reflight of YES2, that would lead to improved preformance and better chances of Fotino recovery:

- Deployment test after tether exposure to vacuum (this was planned but was eventually dropped because of time problems)

- Pre-flight analysis of controller resonance occurrence and identification of the (simple) remedies, which would have avoided excitation of lateral waves and would have further increased re-entry point precision.

- Monopole antenna on FLOYD rather than large hexagon loop (for better reception of MASS data considering reflections of MLI) 

- Redundant capsule beacon system, with monopole antenna's instead of DDRR (more robust).

We keep you informed!