...
- 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.
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.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:
UTIAS: Inform Rob, internal discussion. Size of spacecraft, sharing agreements and so on. Ask for more info when required.
Do following
NTNU:
- 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.