Important notes
Minimum Window Padding
Certain startup and shutdown procedures occur before and after window execution. Windows should not be scheduled too close together or some operations may not complete successfully.
| window type | pre-buffer | post-buffer |
|---|---|---|
| LEASE_ADCS | 420s | 420s |
| LEASE_ISL | 60s | 60s |
| MAINTENANCE | 0s | 0s |
| PAYLOAD_CORAL | 300s | 150s |
| PAYLOAD_DEXTER | 220s | 265s |
| PAYLOAD_IPI | 120s | 210s |
| PAYLOAD_MARSUPIAL | 300s | 150s |
| PAYLOAD_MYRIAD | 300s | 150s |
| PAYLOAD_NANO | 300s | 150s |
| PAYLOAD_SABERTOOTH | 180s | 210s |
| PAYLOAD_SDR | 120s | 210s |
Post-upload Windows
When uploading a file to a payload, the file is held in a queuing area until the first window of a type associated with that payload is executed.
NOTE: This requirement is intended to be removed in a future release.
Minimum Window Duration
| window type | minimum duration (seconds) |
|---|---|
| LEASE_ADCS | 60 |
| LEASE_ISL | 60 |
| MAINTENANCE | 60 |
| PAYLOAD_CORAL | 30 |
| PAYLOAD_DEXTER | No minimum |
| PAYLOAD_IPI | 30 |
| PAYLOAD_MARSUPIAL | 30 |
| PAYLOAD_MYRIAD | 30 |
| PAYLOAD_NANO | 30 |
| PAYLOAD_SABERTOOTH | 30 |
| PAYLOAD_SDR | 30 |
Total Daily Download Volume
Users should limit total downloads to less than 100MB/day
Total Daily Upload Volume and Upload Limitations
Users should expect an average upload volume of roughly to 125KB/day (this can be increased by designating a satellite to prioritize uploads, though this may impact download times). The upper limit on individual upload file size is 10MB. There is an option to manually pre-load larger file packages to a satellite prior to launch if the contract involves a satellite in active assembly.
Upload and Download Time Expectations
Upload times
Please note that uploading a file requires the satellite in question to complete at least one bidirectional contact over a Spire ground station. Depending on a satellite's upcoming contact schedule, even a small file (on the order of kb) can take up to 6 hours from the requested time to successfully upload. As Spire schedules at minimum one bidirectional pass per 6 hour period, upload times will generally be faster than the worst case scenario. The larger the file, the greater the necessary contact time.
Download times
Depending on the difference in time between the end of a payload window and the next scheduled contact, file download times can range between the order of minutes to several hours. If a contract with Spire has specific latency requirements, Spire's engineers will work to facilitate a means of ensuring consistent download times.
Spire's satellites utilize an Sband Radio for their most efficient downloads.
ADCS Priority
It is possible that multiple windows can be scheduled simultaneously that request certain ADCS modes / orientations. While it is not desirable to do this, it is not explicitly prohibited. As such there are certain priorities associated with windows to determine which one takes effect.
All standard payload windows, that allow for adcs_config to be specified, have the same priority. This means that, when multiple windows overlap, the one starting latest will ultimately take effect. Non-standard payload windows that command the ADCS system include LEASE_ADCS and LEASE_ISL.
LEASE_ADCS windows have a higher priority than all standard payload windows since a payload can be commanding the mode/orientation continuously throughout the course of the window. LEASE_ISL windows, since they require pointing the satellite towards its paired ISL satellite, is higher priority than both standard payload windows and LEASE_ADCS windows. For satellites that require stationkeeping, drag/propulsion operations may be scheduled by Spire to do so. These operations will always have the highest priority over the ADCS system.
Thus the order of priority, highest to lowest, is as follows:
- Stationkeeping operations
- LEASE_ISL
- LEASE_ADCS
- All standard payload windows (latest one wins)
Overlapping Windows
By default no scheduled window can overlap with another window, whether that is a payload window, or a contact window that Spire uses for maintenance of the satellite.
There are some use cases, however, that involve overlapping two windows. An example of this might be analyzing some signals captured on the SDR payload, which would trigger an image capture on the IPI payload.
In order to allow for certain use cases, some explicit window overlappings are allowed. Also note that, more than two windows can overlap if each window type is allowed to overlap with each of the other window types. For example, PAYLOAD_SDR, PAYLOAD_SABERTOOTH, and PAYLOAD_IPI can all be scheduled at the same time.
The following pairs of windows are allowed to overlap:
- LEASE_ADCS, PAYLOAD_SABERTOOTH
- LEASE_ADCS, PAYLOAD_SDR
- LEASE_ADCS, PAYLOAD_IPI
- LEASE_ADCS, PAYLOAD_FOREST1
- LEASE_ISL, PAYLOAD_SABERTOOTH
- LEASE_ISL, PAYLOAD_SDR
- LEASE_ISL, PAYLOAD_IPI
- PAYLOAD_SABERTOOTH, PAYLOAD_SDR
- PAYLOAD_SABERTOOTH, PAYLOAD_IPI
- PAYLOAD_SDR, PAYLOAD_IPI
- PAYLOAD_FOREST1, PAYLOAD_SDR
- PAYLOAD_FOREST2_MCU, PAYLOAD_FOREST2_SIGNALING