This document briefly describes some considerations and variants for the communication architecture for the HSI mission.
Introduction and rationale
The numbers and figures in this document relates to numbers in other design documents and are summed up in HSI for CubeSat.
In order to save time, which is likely the most valuable resource for this project, it is advised that the payload downlink (and other communication systems) will be bought together with the satellite bus. The requirements will be presented to suppliers in form of a tender in Q4 '17 or Q1 '18. From this, it is expected that bidding suppliers will suggest hardware and systems that will meet our requirements. Various suppliers will have different equipment and possibly also different requirements/options/offerings for GSs. This goes both for the comm systems (TM/TC, payload downlink, ground stations) as well as software for operation.
Space segment
At the time of writing, a payload S-band (2 GHz) downlink capable of 1-4 Mbps seems reasonable, as it is a product available for CubeSats. These systems will also have an output power that can be supported by the CubeSat. In practice, this output power will be quite low (typical 1-10 W). In order to close the link budget, such systems will require an antenna dish of some size (TBC), perhaps with a diameter of 3 to 4 meters on a steerable mast. This must be verified with a link budget calculation when the space segment sub-system is known.
Suppliers such as GOMSpace, ISIS, ClydeSpace and UTIAS SFL all have S-band radios available. If higher datarates are needed, X-band (8 GHz) can be an option, but availability of such systems will be more limited.
The amount of data generated by the payload must controlled in order to meet the capabilities of the downlink radio system. The communication system might be a bottleneck, so scheduling and operation planning must be done in an efficient manner in order to maximize the amount of data that can be downloaded.
Ground segment
Several architecture options are possible; (1) either only own ground station (possibly enhanced with ground stations at partner universities and organizations), (2) use of commercial stations or (3) a combination of (1)&(2).
(1): At the time of writing, our own ground station is currently not near meeting our requirements wrt. S-band capabilities. The VHF/UHF TM/TC-part is also not fully operational. However, funding for a heavy upgrade looks very promising. We should know this month, I think. The ground station hardware/software could, depending on cost/schedule/options be based upon GS hardware/software from the satellite supplier or set up our own general equipment (or both). An example of a typical ground station can be found here: https://www.isispace.nl/product/full-ground-station-kit-s-band/. Generally, the ground station will consist of antennas (dish for S-band, Yagi for VHF/UHF), amplifiers and switches as well as a radio supported by operation software.
• Partners: Porto, Vigo and also other universities can be potential supporter and help with data acquisition. However, cost and time to build ground stations must be considered (that is why I think we should approach professional operators to have at least a fall-back). We should be able to supply a hardware design for a versatile ground station (one version of it is currently being set up at the local radio club ARK) as well as our own; but the partners must endure the time and cost to implement it.
• Access to NASAs huge antennas could be very interesting, especially if things does not work out as it should, and also if we are able to set up more advanced experiments based on the SDR-payload in next steps.
Example:
As Tor Arne says, we have several options for operational ground stations, including KSAT Svalbard (and other locations) as well as perhaps Kystverkets station in Vardø. I believe it would be vise to have access to an operational service to rely on, in addition to:
Operations software
• Again, I think we must know what we have to play with from the satellite supplier wrt. implementing our own software on-top/instead of. Then we can sit down and see if software/toolchains from our partners can/should be used or not.
• I’ve initiated discussions with Statsat; a company affiliated with the space centre and Space Norway. They are doing operations of the AIS-satellites and NORSat satellites. They now have four satellites operational, and a staff of only four-five people doing everything. They are in the process of re-writing their software based on the 5-6 years of experience they now have, in order to further simplify and stream-line operations. They are delivering an operational service for Kystverket, in addition to more ad-hoc support to research teams with other payloads on the NORSats. I’ve invited them and Space Norway to Trondheim in November/December.
• Also KSAT can be approached on this. We will also approach them when other activities are cleared of the list. We have a lot of people we know very well in KSAT at the moment.
I hope this helps clarify my thoughts, and that it can be used as basis for discussions. Please let me know if you think any of this does not make sense.