Kaleb

Indeed. From this point, exiting to the KSC only brings up a black screen (with the exit button at the bottom) and I have to completely exit KSP to continue. I was able to reproduce this somewhat reliably with just the Ordan Telescope mod installed (and, so far, not at all with no mods), so I'm wondering if anyone else can duplicate it as well. Here's the steps: 0) Start KSP with only Stock parts & Ordan installed (no other mods). 1) In the VAB, create a 2-part ship consisting of a small lander can and the (small) Ordan Industries telescope on top. 2) Launch the ship and wait for physics to settle. 3) Right-click + Activate the camera (i.e. look through it) 4) While looking through the camera, zoom in and out (mouse wheel), and wiggle the capsule back and forth (QWEASD) 5) Now hit escape and revert to the VAB. The odd thing is that usually, if I didn't wiggle the lander can back and forth while looking through the camera, this wouldn't occur (although it might have happened once). Its as if the lander can is somehow becoming entangled into the scenery. (So now Jeb is looking at this giant chunk of terrain sitting in the VAB, and saying "Uh, guys? We're gonna need a lot more boosters...)

Anyone else try this mod in 0.21 yet? I'm wondering if my activating the telescope on the pad, then reverting to the VAB was the cause of this (but more testing will have to wait for tomorrow):

Interesting... Was not aware it was not a PID. That raises some questions.

Slightly off-topic, but regarding KSPX's various radial color-coded fuel tanks, I'm wondering whether the ultimate plan (for a future version) is to implement something called "tweakables" which would let you place a tank, then decide what type of fuel goes in it, which would makes those parts redundant. This would also allow tweakable resource containers for the eventual resource system, without needing separate parts to store each resource type. But its good to know that KSPX is still compatible! I thought maybe I had broken the VAB when I tried putting an old and new HECS core next to each other (prompting me to remove all my mods). But now, after reading the forums, I'm thinking it's just because I had mechjeb pre-installed in my KSPX HECS core. And yeah, I miss those mini-ASAS units already. I may try modifying the cfg files for them, to bring them more into line with the new SAS system.

Aviation Lights and Graphotron work (I didn't actually try writing a file, but the GUI was there and seemed to be graphing fine). Edit: Also, from what I've seen so far, the SimplePartOrganizer seems to work just fine as well.

Excellent write-up! Agrees with my findings as well. Semantically, it's odd, though, that I find myself thinking of the new SAS-functionality in terms being an "ASAS" (because it is a computerized PID-controller with no torque, like the old ASAS) rather than a "SAS" (even though it only kills rotation, like the old SAS); and thinking that it is the old SAS that "went away" (since there is no longer a piece that provides non-user-controllable torque). The key point that I'm taking away from all of this is that if you expect to be able to steer anything unmanned, you're going to have to at the very least put something with SAS-functionality on it.

Here's my take on it, based on limited testing and reading the part descriptions. First, you can't go necessarily by the name of the part. You have to go by the capability listed in the VAB/SPH. In 0.20, there were (I think) three types of turning capability: - Command pod (or probe core) torque, which was user-controllable (ship turned in reaction to QWEASD) - SAS torque, which was passive only and not user-controllable. --- Functionally, this had the result of killing rotation. - ASAS provided no torque, but used a PID controller to control other systems (SAS, RCS, gimbals, wings) --- Functionally, this had the result of killing rotation *and* locking heading. From my very limited testing so far, in 0.21, there are two types of turning capability: - Reaction Wheels: Act like command pod torque (user-controllable) but require electricity (usually at the rate of 6E/min/unit of torque, though there are a few exceptions). NOTE: Parts with reaction wheels contain a "Toggle Torque" option on their right-click menu, so you can turn them off to save power (at the expense of turning power, unless you have something else like RCS to compensate). - SAS-Equipped: This is meant to be the flight computer/PID-controller; like the original ASAS it provides no inherent torque of its own, but controls other devices. However, functionally, it seems to behave more like the old SAS, in that it kills rotation, but I don't think it restores heading. As a result, it sometimes tends to drift. It's also rather more sluggish (especially with rolls), and it allows manual turning (yay!). In terms of parts: - All command pods have *both* RW & SAS - All probe cores have *only* RW. Thus, probes may have a hard time holding a heading... - For control parts: --- The Inline Reaction Wheel has *only* RW. This can be used to supplement your torque. --- The Inline Advanced Stabilizer has *both* RW & SAS --- The Large Advanced S.A.S and the Avionics Package have *only* SAS, thus they provide no torque. Edit: @DangerWillKerbinson! Note: Probe cores are NOT SAS-equipped. I suppose you could throw the Large ASAS on a lifter or upper-stage that's launching a probe? Otherwise, I'm not sure I see the use either. Edit 2: What I'd like to see is a probe-sized SAS. KSPX has a probe-sized SAS unit, so it's puzzling they didn't use that. I may see about adapting it once I start reinstalling mods.

I've always thought it was a fusion/plasma-based drive, but augmented with subspace technology to make the ship itself lighter while thrusting. The memory alpha wiki page for Impulse Drive agrees, stating that "The accelerated plasma was passed through the driver coils, thereby generating a subspace field which improved the propulsive effect." On the Driver Coil page, it says that they "envelop the starship in a low-energy subspace field intended to lighten the relative mass of the starship it encompasses. This significantly reduces the mass burden on the impulse drive, allowing for unprecedented rates of acceleration."

This is actually all from last night. No KSP tonight. First, I returned Jeb from his first Minmus landing, and refueled his lander from the tug's excess. I'm going to attempt a second landing to investigate an anomalous mapsat reading, just as soon as I can figure out a good orbit for this non-equatorial site. No pictures here, because I intend to write up a proper mission report at a future date. Then I used the Ordan Industries Telescope to attempt to photograph a Kerbolar Eclipse. Unfortunately, my telescope's highly inclined orbit wasn't quite lined up where it needed to be. Note the Mun ever so slightly to the left of Kerbol, half-hiding in its glare. So instead, I started mapping the Kerby-Way Galaxy. Bear in mind, this is just a scaled image. The full size is (IIRC) something like 18000 pixels wide so far, and I haven't gone all the way around yet... I don't generally build "replica" spacecraft, but I made this Boeing Delta IV Cryogenic Upper Stage using Stock + Spherical Fuel Tanks (+Aviation Lights, because I throw them on everything as a general rule). Reference image: Kerbalized version: Then I kept playing around with the spherical fuel tanks, and accidentally built a SSTO UFO (Unfeasible Flying Object) which Dudski Kerman was kind enough to test fly. Of course, just because I can haul all those empty side tanks up to orbit doesn't mean it's a good idea. I'll bet this thing does really well with asparagus staging...

Bedsprings.

Last night I managed my first extra-Kerbestrial powered landing! I decided to go to Minmus first, instead of the Mun. After landing (successfully, on the first try!), I noticed that my ISA Mapsat had discovered an anomaly on the other side of Minmus. Since my nuclear-powered upper stage has plenty of left-over fuel, I'm going to try to return to orbit, refuel from the upper stage, and make a second landing to investigate. I had a weird Kraken in that game, though, where I couldn't switch vessels in map mode, or return to the KSC. I had to hard-kill the game and reload from a quicksave. And it kept acting like there was an invisible ship hovering (not orbiting) at the point where my lander had undocked from the upper stage. If I stayed centered on that ship for a while, I could even watch my other Minmus ships get slowly knocked out of orbit. Two or three quickloads, (and unsuccessful landing attempts) later, I was still getting the same bug, so I opened the savefile, and discovered an odd PART-less VESSEL section. After I deleted that section and reloaded, everything worked correctly (and I managed to land successfully again). Not sure how that got corrupted (there were also NullReference errors in the log file)... Anyway, today, I DL'd the demo version of KSP on my Dad's computer and showed it to him (I'd been telling him about it for weeks). I built a simple rocket and took it up to orbit, but I was talking with him, and messed up the gravity-turn quite a bit -- we ended up in a roughly 350x50 km orbit that eventually started to slowly decay. In the meantime, I went on EVA, and ended up bouncing off my ship, sending it (and myself) spinning out of control. Because I'm a bad EVA pilot, I ended up over a kilometer away, and under 50% fuel before I managed to regain proper control and return to the ship. Somehow, Jeb got lucky and managed to grab the ladder just as the side of the ship's capsule was spinning under him. Yay! Jeb was saved! My Dad and I were both surprised and relieved. He's not a gamer, so I doubt he'll play it on his own, but I left a shortcut to it on the desktop. Just in case.

You're on the right track here! The ASAS (and many other real-world applications) use what is known as a PID controller (I had to implement one of these in a robotics course, once). PID stands for Proportional, Integral, Derivative. The wikipedia article is somewhat dense, but the basic idea is that you have a variable x that you want to control by creating a response that is proportional to its error at a given time, e(t) = x(t) - x_desired (this is basically a delta, though its not written as such). In addition to just the current error, however, you also look at how quickly the error is changing (d/dt e(t)) and how much error has accumulated over time (Integral e(t) dt). The response of the system (e.g. RCS or flaps) is then determined by a linear combination of these terms. Apparently, the technique of using all three of these terms to determine your response was originally inspired by watching how helmsmen steered ships -- I think that's cool! Instead of using specific constants like "10" and "2" in your formula, the generic approach uses named constants (Kp, Ki, and Kd) which can be "tuned" to values that work best for a specific application. In KSP, you can actually modify these K values directly in the part cfg files, if you so chose. There's also a mod that lets you dynamically modify them in-game. So the overall formula then, would look something like: Response = Kp*e(t) + Kd*(d/dt)e(t) + Ki*(Integral e(t) dt) You are also correct that this only applies in one dimension, and has to be done for all three. Actually, they work along the three rotational axes (roll, pitch, and yaw). One of the (many) improvements to ASAS that's slated for 0.21 is that the PID will be disabled for an axis that you are trying to steer along. So you pull the nose up your aircraft, the pitch PID will be disabled (while keeping the other ones on). This lets you steer with ASAS on! One major thing to point out, though, is that the variable being controlled here is the rotational rate (angular velocity), instead of the bearing. Obviously, the desired rotation is 0. So your formula for the ASAS correction has three terms: Kp * (how fast are you spinning) Kd * (how fast is your spin accelerating) Ki * (how much spin has accumulated over time, i.e. how far off the initial angle are you) It's that last Ki term that tries to put you back to your initial heading, by eliminating the accumulated spin. There's a lot of advanced control theory focused on applying that equation, which is well beyond what I know, but these are the basics.

Walking up a steep hill, you think "Man, my TWR is to low. I need to shed some outer stages."

You're welcome! (Although, I just noticed I computed those sample acceleration numbers wrong -- they're off by a factor of 60! I can do Calculus, just not simple Arithmetic...)

I need to clear this up: delta-V is *not* the time-derivative of velocity (which is, as you correctly say, acceleration), nor is Isp the time-derivative of acceleration. Dimensional analysis (looking at the units of the quantities involved) is your friend! Delta-V is just the difference between two velocities (its not the derivative, even though it's often written as "dV"), and its in units of m/s, while acceleration (time-derivative of velocity) is in units of m/s^2. Similarly, Isp is measured in seconds, while da/dt would be in m/s^3. Think of it like this: If a car accelerates from 40 mph to 60 mph, the delta-V is just the difference between the two (20 mph, in this case). But the acceleration tells you how quickly that delta-V occurred. If you go from 40 to 60 in 10 seconds, your average acceleration is 2 mph/s (1/30th mi/s^2), but if you make that same increase in speed over 1 second, your average acceleration is ten times that (1/3rd mi/s^2). Isp is harder to quantify in this example, but its an efficiency rating, more like your car's miles per gallon. Except instead telling you the distance you can go per mass of fuel, it tells you the maximum delta-V you can reach when a given fraction of your ship's mass is propellant (according the the rocket equation that others have mentioned).

Here's a fun one I haven't seen mentioned yet: The Ordan Industries telescope mod. It gives you two sizes of space telescope you can put in orbit (the small one's under science, the large one is under command pods). I haven't used the big one yet, but tonight I was just looking through the small one at the Mun, Minmus, and Eve. I tried looking at Duna and Jool, but they're on the far side of Kerbol atm, so the viewing was less than ideal. Chatterer adds some unintelligible background radio chatter, which is a nice touch. Graphotron or Logomatic can send data readings to a CSV file on your computer if you care to graph scientific readings. For parts, I like to include at least one Aviation Light on all my spacecraft. Not sure it increases gameplay per se, but it sure does increase the visibility when the ship is on the dark side of a planet! (I guess if you're building airplanes, you can put authentic red/green/white lights on it.) The Lazor Camera (looks like a webcam, and can pan and zoom) and the Lazor Docking Camera (docking-port-eye view) are also pretty nifty, even if you don't get the rest of the Lazor system. I understand there's weapons in there too, if you're into that sort of thing, though I haven't tried them. If you want to play with airplanes, I've heard Spitfire (which gives you propellers and pontoons?) is pretty good, though I haven't played around with it at all.

Aha! I think this is where our perspectives differ: I don't care so much about *where* as *when*. I've only been going the other way in my computations: I know certain positions along the orbit, and I need to know the time when the object will reach that position, in order to set up a rendezvous. Expressing those times as fractions of the orbital period is useful, because then I can compute transfer orbits with a period that will create an intersection at the proper location and time. Once I know the ratio between orbital periods, it's a simple deal to find the ratio of the semi-major axes, and so on. Interesting... Point conceded (tentatively). I hadn't considered the generalization to e>1. Yeah, in that case I would expect M-bar to be converted to M first, and then solve the equation. You wouldn't want those extra operations every iteration. Like I said, I've (so far) always been going the other way, from true anomaly to mean anomaly.

I've been working out the math this weekend, and I think I have a valid flight-plan for a one-shot/tidy/major-clean (and it's a bit simpler than my previous post). Now if only I can design the ship and figure out how to stick it into the right initial orbit at just the right moment. Just saw the update with Mesklin's time. Under 9 hours? My flight plan would take a few hours longer than that, unfortunately... I wonder if it could be squeezed down some.

Correct, the 2À would appear there instead. But that formula is already computing a parameter (M) from an angle (E), so I don't see any problem with introducing a normalization factor there. And the reverse formula has to be solved iteratively anyway. Granted, this is maybe a good point, but it assumes you don't already have the period computed. If you do, there's no reason to recompute that square root -- it's just as easy to say M = 2À t / P But either way, since the resulting variable is in the range 0-2À, you'd have have to divide by 2À if you actually wanted to know how far into the orbit something was. Which is easier to understand? M = 0.78539816 or M-bar = 0.125 I'd contend that the later is more recognizable as 1/8th of an orbit than the first one. I think that's the core of my problem with M -- as a standalone variable, it doesn't seem to represent anything particularly useful, but if you rescale it, it does. Did you mean mean anomaly here? Or are you talking about iteratively solving Kepler's equation for E? If the later, again, I don't see what the problem is with adding an extra normalization term into an equation that converts from a parameter to an angle. Especially since it already requires numerical methods to solve. If the former, I'm still not seeing the usefulness of calculating M on the range 0-2À. I'll have to give it a look. Thanks!

You're absolutely correct about the nukes being more fuel efficient, of course -- the Poodles burn for less time, but use a lot more fuel. But I was just using these cases as examples to demonstrate the formula. But this formula isn't meant to evaluate engine efficiency; it just determines whether a specific manuever with a given engine is, for example, a quick 2 second burst, or a long 5 minutes of thrusting. And granted, I did forget to account for throttle up/down time. Actually, I deliberately ignored it, in the interest of keeping things simple. That's left as an exercise for the reader. (although for, say, a minute long burn, the effect is negligible).

1) Get a computer 2) Install and play KSP 3) Congratulations! You have just made your computer work like an ASAS! 4) ??? 5) Profit!

So I've been refreshing my grasp of orbital mechanics recently, and reminding myself of the whole true/eccentric/mean anomaly thing. I think I've got a pretty good grasp of them: - True Anomaly (f) is the actual angle from the focus of the orbit to the position of orbiting body (starting at periapsis). - Eccentric Anomaly (E) is a geometrical convenience: the angle from the center of a circumscribed circle (not the orbit's focus) to the projection of the orbiting body onto said circle (again, starting at periapsis). - Mean Anomaly (M) is a "fictional" angle that varies linearly in time from 0 to 2À during the course of a period. I *think* it represents the angle where the satellite would be at a given time, if it were on a circular orbit around the focus. But wikipedia is clear that it is actually a parameter, not an angle. The mean anomaly (M) can be found from the eccentric anomaly (E) and the eccentricity (e) via Kepler's Equation (which has no closed-form inverse): M = E - e*sin(E). The mean anomaly is useful for finding the time at a certain point in an orbit, since the time of a given mean anomaly is just t = M/n (assuming M = 0 at t = 0), where n is called the mean motion, and is related to the orbital period (P) by n = 2À/P. The mean motion is the constant angular velocity of this fictitious angle M. From what I've seen so far, it occurs to me that there's not really any advantage to treating M like an angle. It doesn't represent a physical angle, or interact with other physical angles, and it isn't involved directly in any trigonometric relations. Since it's just a parameter, what makes sense to me is to normalize it, by dividing by 2À, so that it varies from 0 to 1 during the course of an orbital period. Similar to the way that Plank's constant was normalized to create h-bar by dividing by 2À, we could define M-bar = M/2À. Then, to get the time at a location in orbit, instead of dividing by a fictional angular velocity (t = M/n), we simply multiply by the orbital period (t = M-bar * P). This shows that M-bar, rather than being a fictional quantity, is merely the fraction of the orbital period completed thus far (t/P). Furthermore, we don't even need to define mean motion at all. We've "refactored" to eliminate two intermediate fictitious variables, and replaced them with a simple fraction of an existing physical variable. This seems much simpler and more intuitive to me than a non-existent pseudo-angle and its pseudo-velocity. (For example, saying M-bar = .25 makes it instantly clear that an object is a quarter of the time into its orbit, whereas M = 1.5707 may not be immediately recognizable as À/2, and therefore one quarter of 2À. And that's with just a simple fraction.) So my question is, why don't we do this? I know its just a simple matter of scaling, but what is the point of scaling M to the range of 0...2À rather than 0...1? Is this merely a case of "this is the way we've always done it, and it works well enough", or is there some benefit somewhere to keeping M as an angle? Maybe a trigonometric relation that I'm unaware of? I assume Kepler originally derived it in terms of angles, but that doesn't mean we need to stick with that notation if there's a cleaner, functionally equivalent notation. Or maybe people already do this, and I'm just not aware of it? Just my random thoughts. BTW - If you've ever heard of the "Tau Manifesto" and "Pi is Wrong" movement... I had to resist the urge to replace all the 2À's in this post with Ä's. I figured one unconventional notation was enough for the time being.

As a software developer myself, I totally understand ialdabaoth's reluctance to add complexity via wildcard/regex support. But I wonder whether an alternative compromise solution might be acceptable: what if the square brackets after PART could list multiple parts? Maybe comma-separated (or whatever delimiter works)? It would just be a shorthand for typing the same block of text multiple times, but would (hopefully) avoid the potential for unforeseen consequences that a regex might introduce. So it might look something like this: @PART[SomePart, SomeOtherPart, YetAnotherPart, JebediahsPieceOfJunk, MyUberModdedCheatPart] { @MODULE[ModuleCommand] { @name = ModuleSomethingElse } } Granted, you still have to manually update the part list when another part comes along, but at least its all in one place.

When you make a maneuver, you want to start your burn early, so that half of it occurs before the maneuver node, and half of it occurs after the node. The navball usually tries to estimate your burn time for you, but I've noticed that more often than not, it says "N/A" -- especially if you're using RCS or Ion engines -- and sometimes it isn't reliable. I decided to determine the formula for burn time myself, and then I found a simple (-ish?) way to estimate it. This is all pretty straightforward stuff, but I thought I'd share it in case it helps someone. === Derivation === First, some basic definitions: m0 = Mass of spacecraft before burn (in metric tons, i.e. Mg). m1 = Mass of spacecraft after burn. dv = Change in velocity that will result from our burn (m/s). ve = Our engines' effective exaust velocity (m/s) = g0 Isp. g0 = Standard gravity = 9.81 m/s^2 (you can estimate this as 10, if needed). Isp = Our engines' specific impulse (s) -- we'll assume a single type of engine. dm = Mass of fuel expended during burn (Mg) mdot = Fuel flow rate (Mg/s) t = Duration of burn (s) T = Total thrust of all firing engines (kN) We can use the rocket equation to find the mass of the fuel that we burn (dm): dv/ve = ln(m0/m1) m0/m1 = e^(dv/ve) dm = m0-m1 = m0 (1 - m1/m0) = m0 (1 - e^(-dv/ve)) Then, given the fuel flow rate (mdot), we can find out how long it takes us to burn that fuel (t). dm = mdot t, so t = dm / mdot We can find the fuel flow rate from our thrust (T): T = mdot ve, so mdot = T / ve Substituting the formulas for dm and mdot into the formula for t, we get the following formula for burn time: That's the exact equation for the burn time. Don't let it seem too intimidating, because we're going to simplify it in a bit. One thing to notice at this point though, is that burn time is proportional to your starting mass, and inversely proportional to thrust. If you double your mass, the burn time doubles. If you double the thrust, the burn time is cut in half. This may seem obvious, but rocket science isn't always obvious -- for instance, notice that the burn time doesn't scale linearly with dv. That's because our ship is getting lighter as we burn, so our ship gets more bang for the buck (actually, it bucks more for the same amount of bang). That's the nature of the rocket equation. === Estimation === With that exponential term in the formula, its not very easy to use this on the fly. In fact, you might start to pull out a spreadsheet to compute this for you (when the navball doesn't). But that may not be necessary, because we can use a simple linear estimation. To start off, I'm going to define x = dv/ve (that is, the ratio of the burn's required delta-v to your engines' effective exaust velocity). When x is relatively small (dv < ve) we can reasonably approximate 1-e^(-x) with a linear function, kx (for some value of k, TBD). This will give us the following estimation: Note that the ve in the denominator of x cancelled with the ve in the formula, so that this estimate is independent of your engines' efficiency. All that's left is to determine a good k. When I was originally deriving this, this is the point where I went nuts for a bit, and tried (unsuccessfully) to use crazy integrations and least squares curve fitting to optimize k. It's actually a lot easier than that... It turns out that if x (= dv/ve) is sufficiently close to 0, k = 1. This represents the case where your burn is small enough to ignore the effect of becoming lighter as you burn. I realized later that it can also be derived from the first-order term of the Taylor series for e^x. As the size of your burn increases, the effect of becoming lighter becomes more important, so k decreases. Earlier, when I said this was a linear approximation -- I sort of lied... We're actually going to use x to fine-tune our linear constant, so its not strictly linear (we're essentially using a second-order approximation). If we go all the way to x = 1 (dv = ve), its simple to show that k = (1-e^(-1)) ~ .63. So as x varies from 0 to 1, k varies from 1 to 0.6. This suggests a general rule of thumb to determine k: Compare dv to ve. If dv is close to 0% ve, use k = 1. (I check if dv < 10% ve) If dv is close to 25% ve, use k = 0.9. If dv is close to 50% ve, use k = 0.8. If dv is close to 75% ve, use k = 0.7. If dv is close to 100% ve, use k = 0.6. === Examples === Q: You have a 20 ton craft that needs to make a 30 m/s orbital adjustment using 8 RCS quads. How long will this take? A: For 8 RCS quads, T = 8 * 1kN, and ve ~2600. Our dv is small enough that k = 1. t ~ 20/8 * 30 = 75 s Oof! That's a long burn using RCS. Q: How much shorter would that burn be if we used 2 LV-909's? A: Our new thrust is T = 2 * 50 kN = 100 kN. And 30 m/s is still less than 10% of our new ve (~3900). t ~ 20/(2*50) * 30 = 6 s That's much better! Of course, if we only had one LV-909, it would take twice that, or 12 s. Q: How long will you be burning your 4 LV-Ns to send your 100 ton space station to the Mun, if the Manuever Node says it takes 600 m/s? A: Our thrust is T = 4 * 60 kN = 240 kN. For LV-N, ve ~8000. Our maneuver is still less than 10% ve... t ~ 100/(4*60) * 600 = 250 s That's over 4 minutes -- that station is heavy! Q: How long would that burn take using 4 Poodle's instead? (For convenience, lets also say the station is 110 tons now...) A: Thrust is increased (T = 4*220), but now our ve is decreased to ~3900. Our burn is getting close to a quarter of that, so we'll use k = 0.9. t ~ 110/(4*220) * 0.9 * 600 = 270/4 = 135/2 = 67.5 s Only slightly more than a minute.

Aughh! And here I thought I was being clever when I constructed my 4-sat Keostationary RT network by creating a bus-vehicle that coasted an elliptical orbit with a period 3/4ths of a Kerbin day... Just looking at this, markers 1 & 3 share a common AN/DN (only reversed from each other -- one is ascending while the other is descending). But I haven't worked out what the time difference is between their passing of that point. My intuition says its half their period, but I'm pretty sure that's wrong. The same AN/DN relationship is true of 2 & 4, but they're shifted 90 degrees off from the others. So you could create an equatorial, elliptical orbit whose apoapsis touches 1 & 3's common AN/DN point, and whose period is whatever the time is between those two passings (or some multiple/fraction thereof), if that makes sense... You'd drop the first satellite just before reaching that point, then have it make a burn to simultaneously affect a 33-degree plane change and a circularization. In theory, 90 (or 270?) degrees later, the satellite would encounter the marker at its periapsis, and be able to burn to match its velocity (thus raising its apoapsis). Then, at a later point, your deployment ship would reach apoapsis again, and deploy the second satellite. But you'd need a second one of these bus orbits, shifted by 90 degrees, to deploy 2 & 4 from. You almost need 3 buses: one for 1&3, one for 2&4, and one "megabus" to deploy the first two buses into their deployment orbits. The trick is getting the timing right between all these deployments. I'm not quite sure how to do that...