Page History

...

• Self-funded, not-for-profit. All funding from contracts. 35 engineers, 15 grad students. 
• State-of-the-art and low-cost missions
• 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 & mission 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 feasibleis possible. 
• 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. 
• Satellites to note: GHGSat-D and NEMO-AM (Indian and Dubai version), DMSat-1, CANX-7
• Brite satellites were integrated with help with SFL, integrated in Austria.
  
• In Europe it is necessary to deorbit<25 yrs, they have a proven technology that is operational as we speak (-2 km altitude pr. month) with drag sail.
• They work very well with launch providers – SFL asks for modifications and launch providers do - respected for launchers
• Formatting with already deployed solar panels is not a problem, trade-off between cost and risk.
• 
  
  

• 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 .  when harvesting. Don’t go to sleep, you may risk everything and power is worse off when waking up.
• 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. 
    • Calibrate image with star tracker
    • Down to 0.1 to 0.2 degrees
  • During slew, error should be at 0.21-0.1 2 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. 
  • Pointing accuracy: 
    • Limb-to-limb
    • Where on Earth you are w/o sun to saturate star-tracker
    • GPS in all
    • Slew rate not a problem
• Communications:
  • S-band down, UHF up is ok. 
  • Active pointing of the antenna. S-band at 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 Takes 1 day to upload the file, then engage the software that is uplinked on mission files. Then do verification and load. 
  • Ground system bought with platform system
• 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 sorthigh-speed serial 0.8 Mbit/s, on-board storage 1 GB (raw images). Should have around 1 GB storage on the onboard-processing. Also used as buffer before transmit. Have a NSP (nanosat communication protocol). Protocol across the bus, RS45. 
  • Payload-OBC interaction (limited to data exchanges). Could be able to operate on input from the payload, but perhaps go through the GS first. 
  • Kanu (on-board operating system)
    • Runs attitude control and operating software
    • Provide software that interfaces with everything
  • 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.  

• • Mission planning software time-tagged commands uploaded on-board rather than feedback on what’s happening
  • Flat Sat made up by spares – flight model + electronics. They may then work in paralell during integration & testing
    
  • Uplink info on target, then sat will do maneuver (in sense completely autonomous - you just set the target - no magic on mission operations).

• Power

  • Power consumption too high in some parts in the mission design. Put lower. Again payload is important. SFL can achieve better than that.

• Other

  • They do

• 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. 

  • Integration in Norway: host group for integration activities at SFL, work with us to incorporate things at NTNU. Possible. 

Next steps: