Quote from: ChrisWilson68 on 10/30/2019 03:15 pmSo far, RocketLab's launches aren't enough to justify the investment made to develop Electron.We agree on this point.
So far, RocketLab's launches aren't enough to justify the investment made to develop Electron.We agree on this point.
I think some of these payload delivery buses will struggle because in the end they need the rocket to get their solution to space. Their bet is they can squeeze a margin between the end customr and the rocket operator, but that has to either come from the rocket operator lowering prices or the end customer paying more for the service. If you are building and flying the rocket why would you allow someone to insert themselves like that and capture value that you create on a regular basis? Once in a while? Sure. But not super regularly, which limits the volume they can supply.
Quote from: Blackjax on 10/31/2019 12:02 amQuote from: Asteroza on 10/30/2019 11:08 pmA SSO-A related bit here, but if Spaceflight Industries wants to really push the needle on SSO customers, they can take their corncob approach to the next level.Their next rideshare should be a Archinaut/Spiderfab based rideshare mission, where the majority of customers are standardized interface payloads (think MagTag attached). The rideshare bus builds out it's own truss to be a space corral aggregate satellite, while building individual sats with customer payloads and common cubesat buses for customers unsatisfied with the main bus orbit (which means either building up customer sats with propulsion integrated buses, or sats+rideshare OTV). Think taking the A-train SSO observation cluster concept to the next level. Then you are left with the envious choice of delivering the next rideshare bus to an existing populated one to expand it, or shift the next bus to a different SSO position and building another aggregate/build base.Expanding an SSO observation cluster (operating as a space corral aggregate satellite) means you have a regular destination for smallsat launchers as well as larger rideshare buses.So you're basically saying that instead of having them all freeflying, smallsats (which don't need to be in some specific different orbit) could be clumped together, thereby simplifying the mission by eliminating the difficulties of identifying and tracking each one?Well, your basic SSO payload categories (which may overlap) are1. earth observation2. high latitude relay3. demosRemote sensing customers usually have a desire to fly over a specific spot at local noon (thus selecting SSO), but don't care how, and may not even be that specific if their sensor payload can slew. The relay type customer may not be that specific in position (constellation spread dependent but the complete set may be shiftable) but need SSO for high latitude coverage. The demos fall into sensor types (which may need high power) or propulsion types (definitely need power). Being a demo, the sensor types may be more tolerant of not being able to specify SSO position as long as they have power. The propulsion demos are a bit tougher though. Do you really want to mount them on the aggregate coral sat directly (more power, but potentially disturb other customers), or branch off to swapping propulsion demos on an OTV (reusable freeflyer effectively) that is based at the aggregate coral sat, after the OTV is done moving built sats to their own SSO positions?A rough guess is 3 or 4 SSO aggregate coral sats could provide the minimum baseline for "socketed" payloads to hang off of and still have good global coverage of spots near local noon (assuming some slew is acceptable). Since you are building an aggregate coral sat, you only need to deliver payloads, solar array parts, cabling, truss structure materials, and the initial builder, along with any standard buses and their parts for socketed payloads that will be free flying later. The builder doubles as a berthing mechanism system for capturing deliveries.The archinaut demo flight using a Photon base platform could be the seed for an aggregate coral if you wanted the build base up and running before the big rideshare bus arrives. Sensor payload benefit by avoiding deployable structures, leaving that to the builder, plus checkout of everything that isn't the payload by the aggregate coral sat operator during the build. If the sensor payload itself needs deployable parts (antennas, optics, etc), the builder can make it (and probably fix it if they screwed up). This allows sensor payload makers to focus on their core value addition. As for the propulsion demos, if mounted on the aggregate, there is a higher amount of power available than a typical cubesat chassis, plus the ability to do a propulsion checkout, perhaps before attaching to some other bus+tankage. Even if a sensor payload is destined to go off platform as a free flyer, you can check out the core components (payload, propulsion, host bus ACS/comms/power) before release.
Quote from: Asteroza on 10/30/2019 11:08 pmA SSO-A related bit here, but if Spaceflight Industries wants to really push the needle on SSO customers, they can take their corncob approach to the next level.Their next rideshare should be a Archinaut/Spiderfab based rideshare mission, where the majority of customers are standardized interface payloads (think MagTag attached). The rideshare bus builds out it's own truss to be a space corral aggregate satellite, while building individual sats with customer payloads and common cubesat buses for customers unsatisfied with the main bus orbit (which means either building up customer sats with propulsion integrated buses, or sats+rideshare OTV). Think taking the A-train SSO observation cluster concept to the next level. Then you are left with the envious choice of delivering the next rideshare bus to an existing populated one to expand it, or shift the next bus to a different SSO position and building another aggregate/build base.Expanding an SSO observation cluster (operating as a space corral aggregate satellite) means you have a regular destination for smallsat launchers as well as larger rideshare buses.So you're basically saying that instead of having them all freeflying, smallsats (which don't need to be in some specific different orbit) could be clumped together, thereby simplifying the mission by eliminating the difficulties of identifying and tracking each one?
A SSO-A related bit here, but if Spaceflight Industries wants to really push the needle on SSO customers, they can take their corncob approach to the next level.Their next rideshare should be a Archinaut/Spiderfab based rideshare mission, where the majority of customers are standardized interface payloads (think MagTag attached). The rideshare bus builds out it's own truss to be a space corral aggregate satellite, while building individual sats with customer payloads and common cubesat buses for customers unsatisfied with the main bus orbit (which means either building up customer sats with propulsion integrated buses, or sats+rideshare OTV). Think taking the A-train SSO observation cluster concept to the next level. Then you are left with the envious choice of delivering the next rideshare bus to an existing populated one to expand it, or shift the next bus to a different SSO position and building another aggregate/build base.Expanding an SSO observation cluster (operating as a space corral aggregate satellite) means you have a regular destination for smallsat launchers as well as larger rideshare buses.
Likes of Momentus could offer rideshares inside rideshares. They book a smallsat spot for their OTV with SpaceX then sell cubesat spots on OTV to individual customers.
Quote from: Asteroza on 10/31/2019 04:13 amWell, your basic SSO payload categories (which may overlap) are1. earth observation2. high latitude relay3. demosRemote sensing customers usually have a desire to fly over a specific spot at local noon (thus selecting SSO), but don't care how, and may not even be that specific if their sensor payload can slew. The relay type customer may not be that specific in position (constellation spread dependent but the complete set may be shiftable) but need SSO for high latitude coverage. The demos fall into sensor types (which may need high power) or propulsion types (definitely need power). Being a demo, the sensor types may be more tolerant of not being able to specify SSO position as long as they have power. The propulsion demos are a bit tougher though. Do you really want to mount them on the aggregate coral sat directly (more power, but potentially disturb other customers), or branch off to swapping propulsion demos on an OTV (reusable freeflyer effectively) that is based at the aggregate coral sat, after the OTV is done moving built sats to their own SSO positions?A rough guess is 3 or 4 SSO aggregate coral sats could provide the minimum baseline for "socketed" payloads to hang off of and still have good global coverage of spots near local noon (assuming some slew is acceptable). Since you are building an aggregate coral sat, you only need to deliver payloads, solar array parts, cabling, truss structure materials, and the initial builder, along with any standard buses and their parts for socketed payloads that will be free flying later. The builder doubles as a berthing mechanism system for capturing deliveries.The archinaut demo flight using a Photon base platform could be the seed for an aggregate coral if you wanted the build base up and running before the big rideshare bus arrives. Sensor payload benefit by avoiding deployable structures, leaving that to the builder, plus checkout of everything that isn't the payload by the aggregate coral sat operator during the build. If the sensor payload itself needs deployable parts (antennas, optics, etc), the builder can make it (and probably fix it if they screwed up). This allows sensor payload makers to focus on their core value addition. As for the propulsion demos, if mounted on the aggregate, there is a higher amount of power available than a typical cubesat chassis, plus the ability to do a propulsion checkout, perhaps before attaching to some other bus+tankage. Even if a sensor payload is destined to go off platform as a free flyer, you can check out the core components (payload, propulsion, host bus ACS/comms/power) before release.So it would be something like this?https://spacenews.com/loft-orbital-raises-3-2-million-to-build-condo-constellation-for-those-who-dont-want-to-own-satellites/
Well, your basic SSO payload categories (which may overlap) are1. earth observation2. high latitude relay3. demosRemote sensing customers usually have a desire to fly over a specific spot at local noon (thus selecting SSO), but don't care how, and may not even be that specific if their sensor payload can slew. The relay type customer may not be that specific in position (constellation spread dependent but the complete set may be shiftable) but need SSO for high latitude coverage. The demos fall into sensor types (which may need high power) or propulsion types (definitely need power). Being a demo, the sensor types may be more tolerant of not being able to specify SSO position as long as they have power. The propulsion demos are a bit tougher though. Do you really want to mount them on the aggregate coral sat directly (more power, but potentially disturb other customers), or branch off to swapping propulsion demos on an OTV (reusable freeflyer effectively) that is based at the aggregate coral sat, after the OTV is done moving built sats to their own SSO positions?A rough guess is 3 or 4 SSO aggregate coral sats could provide the minimum baseline for "socketed" payloads to hang off of and still have good global coverage of spots near local noon (assuming some slew is acceptable). Since you are building an aggregate coral sat, you only need to deliver payloads, solar array parts, cabling, truss structure materials, and the initial builder, along with any standard buses and their parts for socketed payloads that will be free flying later. The builder doubles as a berthing mechanism system for capturing deliveries.The archinaut demo flight using a Photon base platform could be the seed for an aggregate coral if you wanted the build base up and running before the big rideshare bus arrives. Sensor payload benefit by avoiding deployable structures, leaving that to the builder, plus checkout of everything that isn't the payload by the aggregate coral sat operator during the build. If the sensor payload itself needs deployable parts (antennas, optics, etc), the builder can make it (and probably fix it if they screwed up). This allows sensor payload makers to focus on their core value addition. As for the propulsion demos, if mounted on the aggregate, there is a higher amount of power available than a typical cubesat chassis, plus the ability to do a propulsion checkout, perhaps before attaching to some other bus+tankage. Even if a sensor payload is destined to go off platform as a free flyer, you can check out the core components (payload, propulsion, host bus ACS/comms/power) before release.
Where did you find this graph? And when was it last updated? Seems like 2019 is a bad year even for cubesats.
Quote from: high road on 10/30/2019 09:22 amWhere did you find this graph? And when was it last updated? Seems like 2019 is a bad year even for cubesats.From here:https://www.nanosats.eu/Yeah, 2019, was not a good year, for the launch sector...
With few small LVs offering BLEO launch capabilities, I'm expecting more BLEO missions in next few years. Sounds like RL might do some lunar missions next year, based on Photon announcements.NB there are handful of lunar cubesats that were built for Orion EM1 mission, these are prime candidates for RL.Edit: Between these small LV 3rd stages and smallsat plasma propulsion systems like Phase Four Maxwell missions of 6-8km/s are within capabilities of 130kg wet smallsats.As rough estimate Virgin LauncherOne could deliver 130kg smallsat to earth escape(3.2km/s), 95kg dry mass plus 35kg fuel DV =3km/s. Alternatively 75kg dry mass + 55kg fuel = 5.3km/s.
Seriously? While we all bag on overdone CGI of 'plans', this looks like it was made on a kids learning game program. I mean...come on..
Quote from: xyv on 11/20/2019 04:25 amSeriously? While we all bag on overdone CGI of 'plans', this looks like it was made on a kids learning game program. I mean...come on..If you are referring to the "japanese private launch site 1.jpg" image, that is not CGI. It is a physical model!
People seem to forget that until SX every successful LV was a)Fully expendable and b)Built wholly to a governments requirements c)Wholly (or in large part) funded by that government.The only thing the "commercial" LV builders had in common was their failure to put anything into orbit.
Quote from: john smith 19 on 11/20/2019 05:58 amPeople seem to forget that until SX every successful LV was a)Fully expendable and b)Built wholly to a governments requirements c)Wholly (or in large part) funded by that government.The only thing the "commercial" LV builders had in common was their failure to put anything into orbit. People also seem to forget that Pegasus was the first commercially developed launch vehicle! :-)https://www.northropgrumman.com/Capabilities/Pegasus/Pages/default.aspx"World's first privately developed space launch vehicle."
<snip>Which begs the question: most of Pegasus launches happened in the 90's. What happened afterward? Just the dotcom crisis? I would expect their launches returning to normal afterwards. But they never recovered. Or is this a complex issue I should be asking about in the historical section?
