Hi Craig,
I've definitely given thought to that specifically, a fair bit of thought
actually. Heres my take:
I think it would be hugely beneficial to some payloads, but not all. It
would greatly improve reliability especially among first-time developers
(which is a huge issue, if I recall correctly 70% of first-time university
launches failed due to power/comms). However, the downside is that it
significantly increases implementation complexity, especially with comms.
the deployer provider would need to publish their comms spec and have some
sort of arbitration protocol to decide which payload can downlink when, and
how much.
The other situation where this wouldn't work is swarm payloads, such as IoT
comms constellations. They work based on the premise of distributed links,
and aggregating them.... well... doesn't do that. It may also not work for
some Earth-observation based payloads depending on how many orbits they
wanted to hit. Earth observation and IoT combined are a huge fraction of
the commercial market as well.
Something I've been thinking about is a spacecraft that is half deployers,
half integrated payloads. You could release an updated spec for the
deployed payloads and deploy them at target orbits, and the remaining live
with the spacecraft until end-of-life. If the spacecraft is providing power
to the payloads to be deployed, you could even do something useful with
that extra power post-deployment such as turn the satellite into a radio
relay.
It could even be as simple as using the same form factor for both, the only
difference is one eventually separates from the satellite and one never
deploys. If you had integrated payloads that finished their experiments in
different time frames you could even eject dead experiments to improve
station-keeping propellant efficiency
On Sat, Aug 3, 2019 at 7:35 PM Craig Fink <webegood@xxxxxxxxx> wrote:
Hi Adam,
To me, the next logical step is to conglomerate the Cubesats to eliminate
unNecessary distractions, like attitude control, positioning, supplies,
electricity, .... that can be supplied by the InOrbitCubeSatProvider. Do
what you want in your 1U space ... without wasting space.
On Fri, Aug 2, 2019 at 1:58 AM adam paul <pauladam316@xxxxxxxxx> wrote:
Hi Everyone,
Something I've been thinking about lately is the idea of an updated
version of the CubeSat standard. The standard was originally meant to
define secondary payloads that could be integrated with absolute minimal
obstruction to the primary payload, however, we're seeing several launchers
now (like Electron and Vectors family) that are geared towards CubeSats as
primary payloads.
With that in mind, I was thinking about changes that you could make to
the standard to support this shift in mission design. My first thoughts
were removing restrictions on propulsion and adding electrical umbilicals
between the CubeSat and the deployer. What would be on your wishlist for a
"CubeSat v2"? Would you even use the CubeSat standard at all or start from
scratch?
--
Craig Fink
WeBeGood@xxxxxxxxx
