From SEDSWiki

Contents 1 Introduction 2 Subsystem Representatives 3 Design Session Report 3.1 Structures 3.1.1 Internal arrangements 3.1.2 External arrangements 3.2 Payload (Imaging) 3.3 Payload (uPPT) 3.4 Ground 3.5 ADCS 3.6 Command and Data Handling 3.7 Communications 3.8 Operations 3.9 Misc 3.9.1 Documentation 3.9.2 Umbilical 3.9.3 Interfacing 3.10 Future meetings 4 Recognized needs 5 Decisions Made

Introduction

To coincide with with the 59th International Astronautical Congress, a SEDSAT-2 design review session was arranged. Although not all subsystems were able to be present, those who were were able to present and discuss their work. Various inter-subsystem issues and work-flow issues were discussed and good progress was made.

Subsystem Representatives

• Andrew Bacon, Ground Lead, United Kingdom
• Per Magnus Veierland, Command and Data Handling Lead, United Kingdom/Norway
• Brynjar S. Larssen, Payload team member, Norway
• Steve Maughan, Communications Lead, United Kingdom
• Robert Gmeiner, Structures Lead, Austria
• Tom Nordheim, Payload Lead, United Kingdom/Norway

Design Session Report

Structures

We spent some time discussing the structure of SEDSAT-2, and three main issues covered: internal arrangements, outer shell arrangements and requirements/specifications for the structure.

Internal arrangements

A "Baking tray" solution was discussed which would allow all boards to be slid into the structure from one side, with a cylindrical bar running through all the corner of all the boards to fix them in position. Some questions were raised regarding the thickness of a PCB (hence how thick the tray mounting channels in the structure should be), but the consensus is that this is not a well defined parameter and depends on the number of layers, PCB manufacturer and other undefined parameters.

The CubeSat design spec requires us to center the mass of the satellite, so to aid Structures with this requirements, a guideline was suggested which says that teams should make considerations (where possible) to center the mass of their components on the PCBs.

Regarding the camera, it was suggested that the imaging sensor should be mounted on a small daughterboard which sits vertically (ie. perpendicular) on either the payload or the Power PCB, running along one edge of the PCB. The satellite will be pointing towards the earth and it was mentioned that it would be desirable to get perspective pictures of the earth, ie pointing some angle away from nadir. To achieve this, the daughterboard could be rotated slightly when viewed from above, so that the imaging sensor points away from nadir when the satellite is pointed towards nadir. Some questions were raised about what daughterboard rotation angle would be needed to achieve visibility of the curvature of the earth given that we're at 700km altitude. It was also mentioned that the vertical mounting of the daughterboard could be assisted with mounting brackets similar to those used on eg. slot-1 CPU/motherboards.

It was also debated whether the imaging sensor daughterboard should be physically mounted on the Power PCB. This was because the power PCB will have batteries so will be the heaviest board, and the heaviest board should be as near to the middle of the satellite as possible (for the center of mass requirement). I seem to recall that we only considered the camera being mounted centrally on one face of the satellite, but I'm not sure why at the moment, or whether I'm not recalling things correctly... Tom? Brynjar? Anyway, additionaly, the batteries on the power PCB will have some height, possibly more height than normal PCB's, and if the batteries don't take up all of the power PCB, then this vertically mounted image sensor daughterboard could use some unused space around the batteries. See the sketches below to get an idea of the daughterboard arrangement on the Power PCB.

External arrangements

Solar panel on nadir-facing side of satellite - is it needed or not? Albedo is only about 30% the brightness of direct sunlight, but power specify that they need 2 panels on each side of the cubesat.

Payload (Imaging)

Considering the nature of the image processing tasks that are to be performed by the Payload Processing Unit (PPU), it has been suggested that the onboard Atmel UC3B microcontroller could run a Linux based operating system. This would potentially shorten the development of the subsystem as pre-exisiting code could be used for the camera interface. In addition the Linux operating environment presents us with 'in-the-box' functionality such as file system support, which would eliminate the need to implement this from scratch, as would be the case if the PPU ran a standalone embedded application.

Also see Structure discussion for some other comments on camera positioning within the structure.

Payload (uPPT)

Some questions were raised about the aim to include a uPPT in the satellite. This has implications for the internal layout of the satellite and the demands on the Power subsystem. We realised that our knowledge of the uPPT was fairly limited, and we had no concrete numbers for mass, volume or power requirements.

Ground

Discussions with GENSO (Global Education Network for Satellite Operations) members has raised the issue of possibly connecting the primary ground station to the network, with further analysis required of the implications and feasibility of this. Using the equipment and design advised on the GENSO website will also be considered, which would make the primary ground station a 'GENSO Standard Station'.

ADCS

Command and Data Handling

We discussed a Java I2C control program for testing each subsystem. Network support within the program so remote integration testing between different subsystems (connected by the internet) was also suggested.

Communications

Work took place on defining the interface between comms and CDH. It was decided that Comms does not need to provide an entirely reliable system, as CDH will not remove Payload data from its memory until a delete command from ground is received. Also, Comms should flush it's transmit buffers each time CDH instructs Comms to change from reliable to unreliable transmission mode (and vice-versa).

Operations

Speaking to Jim Voip, he strongly recommended that we define the Operations stage of the project now, as this could have a significant impact (and place specific requirements) on the design of the satellite.

Misc

Documentation

The issue of documentation was brought up a number of times. The most obvious example was the use of PPT's. Some team members at the meeting were believed that the uPPT was already a design goal, whereas other team members did not know this. We agreed that we need more documentation on these issues so that people know what we're working on, and can adjust their designs accordingly. It was suggested that Systems might be well placed to lead the effort to more stringently document the development and progress of all the subsystems (and of the overall satellite).

Umbilical

We need an umbilical cord for testing/reprogramming/powering the satellite after we have sent it away for integration into the P-POD. Someone needs to be actioned to look at this, perhaps CDH, but they will also need to make Power aware so that power can accept power supplied from the umbilical, which is then regulated and sent out to all the other subsystems.

Interfacing

The physical interfacing of satellite subsystems was discussed. Some options are rigid connectors (such as on Pumpkin Cubesat), or flexible connectors. Some concern was raised about the mechanical stress on rigid connectors during launch/vibration testing, although ClydeSpace (who were exhibitioning at the IAC) claimed no problems with mechanical stress and rigid connectors. However, the physical connectors do take up a lot of space.

Another interfacing issue was whether a "motherboard" should be used, or whether one of the other subsystems (eg. CDH or Power) should act as the motherboard. The electrical interface between boards will consist of control/data lines and power supplies. If we have a common motherboard, both control+power can be routed onto the motherboard, and from the motherboard to the appropriate subsystem. Without a motherboard, do we need two connectors on each board - one to CDH and one to Power?

Future meetings

A lot of useful, valuable discussion took place at IAC'08 on a range of issues. It was generally agreed that more in-person meetings like this would be very useful, and probably more often than every year at IAC. Another team meeting was suggested, perhaps in Austria. Flight sponsorship could be sought to assist the team members who are not based in Europe.

Recognized needs

• Detailed information on Pulsed Plasma Thrusters
• Further funding required
• Recruitment of additional team members (especially for CDH, Systems and Payload)
• Further "real life" meetings between at least some of the subsystems

Decisions Made

• Design review reports shall be approximately 5 pages.
• Protoforge shall be used to track design choices. The Systems team will be responsible for keeping it up to date.
• The operations team shall consist of the entire Ground team as well as at least one member from each subsystem team.