You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

DRAFT, NOT FINISHED


Simon C. O. Grocott. Dept. director, missions. Tor Arne, Mariusz, Roger
Simon has a question about absorption through the atmosphere vs. irradiance from the atmosphere. Ref. Mariusz slide 20. 
Signal from the surface will be absorbed through the atmosphere. In addition the atmosphere will "reflect"/irradiate at the same time... --> Both effects come into play? It is OK. this is what the sensor SENSES at the sensor, just could not explain it properly. It shows the total irradiance sensed at sensor vs. what is sensed on surface (reflection+radiance+everything). Delete sentence, just confuses.
Question on what kind of partnership we want. --> We want an active partner, more than a pure supplier.
Exchange students: Depends on the university say, don’t generally train foreign students (have to enroll in university) but exceptions can be made. Training upon contracting partnership is completely possible. 
Notes from presentation of UTIAS: 
  • 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) is 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.


Constraints/requirements
  • 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.1-0.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. 
    • Takes 1 day to 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 high-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 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: 

UTIAS: Inform Rob, internal discussion. Size of spacecraft, sharing agreements and so on. Ask for more info when required. 
Do following
  • Estimate size of s/c
  • Sharing agreements and license software
  • More specific requirements on the functional side and on the slewing/downlink/uplink schedule
  • Downlink should be flexible - determine constraints for that
  • Provide power consumption analysis, energy budget, comms. link duty cycle
  • Prepare list of initial reqs in order to get a ROM.  
  • No labels