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

Compare with Current View Page History

« Previous Version 6 Current »

DRAFT - NOT FINISHED
Participants: Marco Villa - Background from Uni Kansas. Started a CubeSat project there. Currently little activities there, since the uni did not transform from project to program. 
Mariusz, Roger

Lab-tour

  • Marco showed us their lab, where they build, integrate and test their CubeSats. Assembly on Flow Benches; which is an open, but air-flushed lab bench that gives near-cleanroom working surface. More than sufficient for most satellites. If they have optics then there will be stricter rules. According to Marco it is more about the psychology of workers and the rooms are sufficient enough for being clean from air particles.
  • They do their own design of PCBs, but assembly is outsourced (sensors + FPGA).They do however make changes, fixes, replacing circuits etc. in-house. 
  • Well-developed process and information/documentation sharing via online systems, for each customer such that time difference (imagine Norway-US) does not matter. On-demand and efficient, where the customer and provider may iterate real-time on systems and mission requirements.
  • Using flat-sats as a common platform during integration. The flatsat can be at Tyvak; customer has remote access, or the other way around. 
  • Thermal vacuum and temperature cycling is performed several times during test and assembly. Shaking is performed at other locations. 

Minutes

Marco is COO for the US branch and CEO in Italy. Worked with SpaceX for several years. Worked with Dragon Capsule as a flight director for reentry. Also worked with Smallsats on the East-coast. He has experience at leading from 100 to 4000 persons... Univ. of Kansas has a lab called CRASES (?) flying UAVs for monitoring ice thickness in Greenland and Antarctica. 

General

  • Tyvak is also very interested in subsea-activities. Marco is very interested in knowing more about AMOS and loved the concept of the autonomous architecture, especially the AUV part. He was impressed by this concept as he sees full potential of satellite with surface validation and autonomous vehicles (satellite is not the answer alone - nor is the size - it is how and for what you use the satellite).
  • Tyvak also has a EO-activity on-going. Have some profiling algorithmes for processing. Not HSI. (probably MSI?)
  • Working with Fugro (Space Norway) on GPS. Assisted by ground beacons. 
  • Mission for US-army for comms. with low gain unattended sensors (100-1000 sensors/pass). Could have UAV dropping sensors into areas, and then communicate with that. 
  • Inter-vehicle links. Use of Globalstar. Can also go satellite--UAV. Also applies for Pathfinder(?) for Ames. They are working closely with NASA Ames.
  • Possible launch: SSMS with Vega in 2019?
  • Tyvak would also be able to build the payload hardware to get a higher level of integration too. 
  • Have flown target maintaining-tracking with 3 U and 6 U for EO (applicable to our concept). Flown IR-camera. Also doing that for comms. studies. 

Discussed topics during presentation of the HSI concept

Communication: 

  • S-band 2 Mbps is well achievable. Demonstrated at Tyvak.
  • GS-antenna: 3.7 meter. Turn on radio at -5 deg to 180 + 5 deg, usually not a problem with low elevation angles. 30 deg is too high. 5- 8 is appropriate according to what Tyvak may achieve (S-band but easily also for X-band).
  • Have a backup in the mission by using UHF and more compressed data --> it should not be a problem for us then. 
Power for bus:
  • 12 W or so is feasible. Low power design is an important topic for Tyvak and they will optimize it.
  • 5 W (avg) is fine for 3 U. 10 W for 6 U. Peak power is not a problem. 
  • Payload and power on for a short time can be better than sequencing. 
  • Thermal planning can be bigger issue than the power budget when having long duty cycles. 
Mission planning and time schedule:
  • Don't do too much working on (power) budgets. The numbers will change when we get in contact with the provider. They will have to do their own calculations for other optimizations in order to make the best bus possible. 
  • Comment to the time-slide: Move everything to CDR up to right after newyear. Need the most time for integration. Must be 40/60 at least for planning/integration. Get hardware as fast as possible and start working. 
  • Payload is good enough already. If things change 10-20% from now, does not matter. Start working. 
  • Tyvak has no set reviews during design/production.
  • Should have a Feasability review (if it is possible).
  • Do a short design phase. If short is not right; engineers are bad, or the feasibility is bad. 
  • Get the flat-sat on the bench as soon as possible. 
  • Important: What is the level of quality of the image to meet the minimum mission (i.e. when viewing at slant and current optics).
  • Do sensitivity analysis on main drivers. Is it SNR or something else?
  • Study duty cycle further (ConOps)
  • Would challenge us on everything on level-2 reqs. Because that depends on the bus. 
  • There can be potential for cooperation with the Tyvak department in Italy also (10 employees). 
  • Tyvak has not flown HSI yet. Was approached by a customer that (in Tyvaks opinion) did not have a good mission --> thus they didnt want to do it. 
  • This mission is evaluated as a much better case (partly due to the science driver and autonomous coordinated architecture with several robot agents). 
  • Flight candidate on SpaceNorways satellite?? Marco suggested us to put ours as a candidate, he would be happy to coordinate.
  • Minimum amount of time of operation is so small that a separate satellite might not be required (1 image per day is fine to begin with - no matter where it is). 

Other topics

  • SDR: Dont want SDR in the bus. As a payload, SDR is fine as long as it is useful for something 😃
  • Configurable bus: Not really want to give access to ADCS. Its designed to do it, but have not done it yet. 
  • If you start playing with parameters with Kalman-filter and so on, you have disvalued all mission planning so-far. But you may set parameters within a range in coordination with Tyvak. This comes for the EKF, Controller and slewing operations which shall be optimized for the mission target acquistion anyway. 
  • The same concerns the payload (of course) and OBC access. Read-out of data is ok.
  • Find sizes for FPGA-images, they are a bit dubious as of now but are feasible. A question: we need S-band receiver? Take more images in one pass and be flexible!

Level of access to software: 

  • Only binaries + config-files not the source code (never)
  • Payload interface board: Will have its own processor. Low levels (interface to the rest). We dont get a ICD for the bus, but the ICD for that processor. 
  • Have a full fault and tolerance matrix. High level of (FTDIR??) supervision and control. Has a "envelope of flight". Does not want customers to "destroy" the bus. 

Is a user centric company. The satellite is a tool to fullfill the project of the customer. Mission is essence, Tyvak does not sign up for experimental and "useless" missions. They want to succeed but they also want you to succeed. Also willing to invest in a pipeline of satellites & coherent mission & vision, not interested as much in only investing in one sat. 

Follow ups

  1. Provide power budget
  2. Energy budget and duty cycle for imaging & downlinking
  3. Data budget (more clear and determined sizes) - go for more images - not the minimum
  4. Do more detailed sensitivity analysis on HSI and determine asap if we can see something with it from space - Marco suggested to test & get images and relevant profound analysis from the actual camera we have now to determine feasibility and what we may expect to work and iterate on. 
  • Apart from that don't bug Tyvak too much until we have decided it is a path to go on with given a long-term partnership and it looks like we will work with them.
  • No labels