UTIAS October 2017

DRAFT, NOT FINISHED

• Self-funded, not-for-profit. All funding from contracts. 35 engineers, 15 grad students. 
• Have 18 sats operational. 15 awaiting launch.
• Can vere open for exchange/research stays. Must be, to some extent, clarified and organized by the university itself. Must clarify opportunities. 
• Smallsats are a design approach, not a size. 
• Not doing a lot of CubeSats, but are open for it, esp. if its a longer series of satellites. 
• Integration of spacecraft on-site (NTNU) can be feasible. 
• Launch: Have supported a wide range. (Must get a up-coming manifest). 
• Typical orbits are 500-650 km, 09:30 - 10:30 ascending/descending node. 

• Sleep-power: Will be higher than "expected", need to keep a reasonable amount of minimum operations in order to ensure good operation and wake-up. 3 -  4 W. 
• ADCS: 
  • Must look into this exp. on 3U. On bigger buses this is less of an problem. 
  • Pointing knowledge with star-tracker is very good. 
  • Pointing accuracy it more challenging, but should be better than 0.5 deg if good calibration. 
  • During slew, should be at 0.2-0.1 during maneuvers. 
  • The type of reaction wheels must be looked into for 3 U. A bit more of a challenge. 
  • Limb-to-limb pointing might be a issue, as to find where the star-tracker can point. 
  • Must avoid sun into the sensor. 
  • Higher latitudes should be fine, but further south might be more of an issue. 
  • Can be a bit of a time-variance wrt. position of sun/moon/earth-interactions. 
  • Have GPS, better than 10 meters. 
• Communications:
  • S-band down, UHF up. 
  • Active pointing of the antenna. 2 Mbps (with pointing). 
  • Standard, nominal, mode is more like 128 kbps --> works for all attitudes. 
  • Uplink is typically 4 kbps. Have always supported re-programming. 
  • Spend a day to upload the file, then do verification and load. 
• Integration/test
  • Operational software are available. Encourage testing using operational software during tests on ground. FFI and Statsat have this. 
  • Training: Can happen at UITAS, or NTNU. 
  • Have a flat-sat, made up by spares. Could then be used as spares for the flight model if needed. Does not really make an EM of flight heritage components. Go right to proto-flight if its only small changes. Does not expect any new equipment, but will probably have some suggestions on how to build the payload. 
  • On-board interfaces: Communication limited to 1 Mbps or 500 kbps. CAN or serial of some sort. Should have around 1 GB storage on the onboard-processing. Also used as buffer before transmit. Have a NSP (nanosat communication protocol). 
  • OS: Cano. In-house system. Not really open for us. ADCS is probably not really accessible; perhaps with permission. Could provide some interface of to software that we could run. 
  • Interaction between payload and OBC: Should be limited to data exchange. Commanding should go through mission planning software (GS). Upload target, time, when. Time-tagged commands. Not any feedback on what going on. Onboard autonomy means different things.... Using a hand-full of high-level commands. Like "point here", take image. The detailed maneuver will be solved in the space craft. 

• Could be able to operate on input from the payload, but perhaps go through the GS first. 
• Does not currently have SDR. 
• Export: Formally, will need an export agreement, should not be a problem. Need to look into which students can be in the project and so on.