K^2

1. Infinite. Otherwise, you have to specify tolerances. And then the math gets really hard. But the gist of it is that "high enough to complete transfer before your anomaly changes drastically." 2. Optimal descent is not the suicide burn, except for the actual touchdown, which is almost trivial fraction of dV under right conditions. For an airless body, you first need to transfer to the orbit that has periapsis just above surface at the target sight. I'm not giving exact formula here, because this might involve inclination changes and bi-elliptic transfer. You can look up various transfer formulae. From there, the remaining dV is your periapsis velocity - surface velocity + g * T, where g is surface gravity, and T is time until landing. The later will depend on TWR, and is also not a trivial quantity. But T = v * m / F is a first order estimate, where v is velocity you need to kill, m is mass, and F is thrust. If your TWR is high, this will be fairly precise. If your TWR is only slightly above 1, this will be badly off. If there is atmosphere, descent is either free or very hard math. 3. For an airless body, identical to descent. For a body with atmosphere, very hard math. A rough estimate penalty for ascent in atmosphere is 4gH/vt, where vt is terminal velocity at launch sight, and H is scale height. But this is a VERY rough estimate. In general, simple formulas exist only to a tiny subset of problems. In majority of real scenarios, there are numerical methods that can give you desired solutions. But it's something you write a program for. Not something you just punch into a calculator.

While "orbital insertion" is definitely what you're looking for, one of these could be a part of orbital incursion. Perhaps as an orbital diversion or an orbital dispersion. Either way, there is no doubt of orbital controversion over such orbital assertion.

You wouldn't want to use Euler angles or anything similar, yes. But describing mechanics in terms of quaternions is awkward. It can certainly be done, but I wouldn't bother. Just use 3x3 rotation matrices. They avoid singularities just as well as quaternions do, but the math is easier to carry out, and rotation matrices have convenient intuitions about rows or columns as coordinate axes. Something that quaternions certainly lack. And there are standard formulae for extracting Euler angles from a rotation matrix if you need them for output or debugging. As an aside, it's worth pointing out that rotation with quaternions and matrices are very closely related. The multiplicative group of unit quaternions is homomorphic to SO(3) group, which contains all matrices you'd use for rotation. That is, for every rotation matrix, there is a unit quaternion that describes the same rotation. Two, in fact, since changing sign of the quaternion doesn't change rotation it describes. So anything you can do with one, you can certainly do with the other. But your mileage may vary on implementation. Matrices are easier to work with, which is why I recommend them here. In contrast, quaternions take up less space, which is very important in cache optimization, and highly optimized code for quaternion math can be a little faster than matrix equivalent. Both of these make quaternions preferred method in video games. There are also some skinning techniques that leverage quaternions' better behavior under interpolation, such as Dual Quaternion Skinning, but that's getting way off on a tangent. Some of these considerations may be valid for physics simulations in certain contexts. It's not something you'll ever have to worry simulating a few rigid bodies, though. There, I would absolutely place simplicity and better intuitiveness of rotation matrices above any computational edge you might have with quaternions. As a general rule, whenever correct beats fast, I would skip quaternions.

Well, for starters, from perspective of outside observer, you never do fall in. You'd be falling faster and faster, and indeed, approaching light speed, but the time it requires for light to escape also increases. From event horizon, light takes exactly forever to escape. Everything that ever has fallen into a black hole appears to still be falling to any outside observer. To anyone who has fallen in, the trip is much, much shorter. Again, no object is at the event horizon from perspective of outside observer. But yes, they can appear to be very, very close to light speed. Again, from perspective of the person falling in, the fall can be quite short. Moreover, person falling in never crosses event horizon. As you get closer, the event horizon appears to deform out of the way, then envelop you forming a bubble. That bubble then shrinks as you get closer to singularity. Then finally, at one moment, the black hole, the bubble, and you become a single point. That is the only singularity you'll actually encounter as the person falling in. For a supermassive black hole, surprising length of that harrowing experience is survivable. You can be well bellow the event horizon and still not having encountered anything that would kill you outright. You will get to conditions no living being can survive well before you actually encounter singularity, though. Back to the outside observer perspective, your rest mass appears to decrease, as your potential energy is converted into kinetic. The total mass actually stays constant throughout the fall, since no energy is added from any outside source. In general, from perspective of outside observer, matter approaching event horizon starts becoming indistinguishable from light. It all travels at light speed and has no rest mass.

Simple physics simulation is basically just numerical integration over Newton's 3rd Law. For general problems, it can get quite complicated, but for simple trajectory computations, Velocity Verlet is usually quite sufficient. Just keep making the time step smaller until results converge. If drag gives you trouble with Velocity Verlet, you can try generic RK4, but I doubt it'll be necessary. The only notable exception is gravity simulations. These tend to go bad with explicit integration methods over any significant time scales, and you have to do something funky, like implicit collocation methods. But unless your goal is predicting trajectory of a spacecraft in interplanetary space over the next several decades, you simply don't need that sort of precision. For everything else, Verlet has you covered 90% of the time, and RK4 picks up the slack on the rest. So if you get comfortable with these two methods, you have numerical part down. The rest is just picking the right models. Gravity is a constant force for your case, so that's easy. Simple quadratic drag is good for air resistance until you get into transonic speeds. Engine thrust is going to be tricky. You can get general thrust profiles from manufacturers, but the tolerance on these tend to be bad, so you'll have to add some random variation to have something resembling a real engine. If you encode the thrust curve with something like Bezier curve or cubic spline, moving a few control points around by small random amount, say 10%, should put you in a ballpark of what to expect. You'd have to read up on manufacturer docs to get more precise. But if your method will work with 10% variation in control points, it'll probably work with real engines. If orientation of the rocket changes, things get a bit more complex. You have to do rigid body physics, for which the key concepts are angular momentum and moment of inertia tensor. Integrating orientation can generally use the same basic principles, but the actual EoMs for bodies with non-degenerate axes can be a touch overwhelming. There are some variations, but by far the cleanest approach is simply to go with Euler's Equations. Things get further complicated by orientation changes in terms of aerodynamics. The drag coefficient will vary with orientation, and your body and control surfaces may start developing lift. Here, things can get as complex as you'd care to press them. But honestly, if you get to a point where it matters, this project probably has gotten a bit out of hand.

If the clock signal is available, yes. But we also have types of digital media where it's not, like compact disc. There you have things like requiring that no code point consisting of only zeroes is used, meaning you will have a signal at least every so often letting you re-calibrate and adjust for slight difference between physical speed of the disk and expected clock rate. It also helps that ones are encoded as the change in the depth of the disk, rather than specific value. But this has more to do with the fact that interferometer is used to read the distance, and that's really good at telling that distance changed, but not necessarily whether it got longer or shorter. Still, it works out to make tracking of the medium's speed a bit easier, so it's an added benefit.

Reading timing is harder, because it varies with your input rate, especially for inexperienced operator. But I'm almost certain I've seen software that does it. There's also minor complication in variation of input styles, like fast double dit for dah. But this can be a toggle flag. Not something that needs to auto-detect.

Depends on how quickly and how precisely you need corrections. You probably want at least an order of magnitude between reaction time and update frequency. So if you need course corrections to take within a second, tenth of a second is probably fine. But again, depending on just how precise you want it. In practice, update frequency of PID algorithm is almost never a limiting factor. You can even build an analog circuit that performs PID, outputting directly to a servo. And even with a chip, it's a very simple algorithm. The most basic micro controller can run it hundreds of thousands of times per second without breaking a sweat. So your limiting factors will have more to do with mechanical systems and sensors. For example, some sensors become "noisy" if you increase sampling rate too much, so they start generating errors. If you have a straight up PID hooked up to that, your control output will be bouncing all over the place as well, and that can be bad for your systems. So you can either decrease sampling rate to get better measurements, or filter your senor input. (Or both, in practice.) Either way, your response time will get worse. Mechanical limitations are easier to understand. There's only so fast you can make various servos move before you either break something mechanically, or burn out the motors. If fins on your rocket take 100ms to respond, there is no need to update your PID a million times per second. The errors resulting from PID update times being discrete are very similar to what you get in numerical integration. Moreover, basic PID essentially gives you Euler Method, which is the most error-prone of them all. Fortunately, the damping term in the PID is the very thing that helps you not experience too much problem with it. If D term is too low and P is too high, PID will start oscillating with higher and higher amplitude. But if your D term is close to critical damping of the P term, and P is small enough to give you at least a few updates within the response time, these numerical errors just make response time slightly sub-optimal and/or cause tiny overshoots. I would point you to the spreadsheet I posted above, but because I was lazy and only set it to 10 updates per second, I actually modified the PID algorithm slightly to reduce integration errors. So you'd have to go to some really silly P and D values before it's obvious.

My Latin's rusty, so this is based more on the general knowledge available at the time and the state of early Calculus than on actual reading of the Principa text. But Newton had all the machinery to realize that a spherically symmetrical body has the exact same gravitational pull as a point mass. Once you have a hypothesis that force of gravity drops as inverse square of the distance for any component masses, deriving the fact that planets will have force between them proportional to total mass and inverse square distance between their centers is relatively straight forward. Which then confirms the inverse square hypothesis via Kepler's Laws. Showing that Elliptical orbits satisfy both is a bit more work, and I believe initial proof is due to Hooke. Anyways, where I was going with this is that it's very likely that Newton would have pointed out that spherical bodies behave as point masses. That's not the same as saying that objects have no self-interaction via gravity. Just that we can ignore it while talking about motion of planets and other celestial bodies. But it could possibly be misread to imply it. As for actually showing that a shape of a planet should be roughly a sphere, the simplest argument is via potential energy. A more rigorous proof involves a bit of Calculus of Variation. So I don't know if a good way to prove it was available to Newton, but it's a pretty intuitive notion that things trying to clump together as close as possible might make a sphere.

Depends on which multiverse you're talking about. In Everett Many Worlds, all "universes" are just alternate history states of a single universe. On the other hand, certain branches of String Theory suggest possible existence of multiple branes within the bulk, which would result in some number of worlds, possibly finite, and in some models as few as two. In that case, bulk is the meta-universe you're suggesting.

EDIT: I've made an interactive example of the following in a Google Drive spreadsheet. You won't be able to edit it, but if you want to play with the inputs, you should be able to save a copy to your own drive, so long as you are signed in to Google. There are two boxes that describe initial state of the system and the PID parameters. These are the values you can play with to see how it affects response of the system. Link to the spreadsheet The computations are done via a dirty Velocity Verlet integration, but it's good enough for this demo as it turns out. Original text with way more math follows: I don't know if I can give a simple explanation, but I can try for one that can be logically followed and with pictures! PID can apply to many different states, but it's easiest to think about position of something. Lets start with PD terms. The idea is that we have an object that's initially at some position x0 moving with some velocity v0 and we want to bring it to x = 0 and keep it there. So we can write down equation for position of the object x(t) before we tried anything as function of time: x(t) = x0 + v0t We are also interested in the rate of change of position x, which is velocity v(t), but we often denote as x'(t) to explicitly specify that it's the rate of change of x. If you look at Wikipedia article on derivatives, you can probably follow along, but in either case, the correct expression is: v(t) = x'(t) = v0 None of this is what we want, though, as we want x(t) to go to zero. Simplest thing we can think of is to push on object towards the center, and the force should probably be proportional to how far we moved the object. It's fairly arbitrary what to set proportionality constant as, but typical choice is to have F = -ω2m x(t). Here, ω is related to time scale on which you want the system to react, and m is the mass/inertia of the system. Together, m/ω2 is the P term in the PID. Using Newton's third law, we can write down the equation for the rate of change of velocity, which is also known as acceleration, or second derivative of position x''(t). a(t) = x''(t) = F/m = -ω2 x(t) And rearrange it slightly to take it to standard form: x''(t) + ω2 x(t) = 0 subject to x(0) = x0, x'(0) = v0 That's a differential equation, and solving these is outside of the scope. But the solution to this has fairly straight forward form. x(t) = x0cos(ωt) + v0sin(ωt) So that's a start, but the object isn't staying at x = 0, it overshoots it. And the reason is pretty simple. If the object is already moving towards center, we shouldn't be pushing it to move even faster. In fact, we should be slowing it down. So we augment the force with a damping term which simulates friction. Intuitively, you expect something oscillating back and forward to slow down and settle at zero if you have some friction. And there are different ways to express it, but the mathematically simplest is to introduce a damping term ζ. The reason is that ζ = 1 gives us optimal decay towards x = 0 without any rebound or being too slow. Without getting into too much math, the D term comes out to 2ζωm, giving us the drag force FD = -2ζωm x'(t). This gives us the new differential equation. x''(t) + 2ζω x'(t) + ω2 x(t) = 0 subject to x(0) = x0, x'(0) = v0 And again, without getting into the math of how this is solved, for ζ = 1, the solution is: x(t) = (x0 + (v0 + x0ω)t)e-ωt So this does precisely what we want with just the PD terms. Which brings up a question, why do we care about the I term? Well, real world tends to be nowhere near as clean. Realistically, there are always additional forces acting on whatever it is that we are trying to control. Imagine that there is some force pushing on the object in the positive x direction. We plug in all the same PD values, and this happens. Not a total disaster, but if we were using this for some sort of steering, we're definitely off course. And this is where the I term comes in. The general idea is that since the object is definitely at rest, only the P term is currently holding it where it is. Which means that the force we're generating due to P term is equal to the force acting on the object. So the average displacement over time tells us something about the correction we have to apply. The total area under the curve, also known as the integral, is the relevant quantity here. I'm not going to get into the math of it. But let me throw in the I term just to show the end result. Note that it definitely overshot the zero, and now slowly making the way back. It suggests that my tuning of this PID isn't great. But unlike just the PD portion, where I could upfront say what the good values are given reaction time I want, once you throw in the I term, things get a little worse. I would have to have some advance knowledge of the typical forces we're likely to encounter and make some assumptions based on that. Alternatively, you can do what a lot of people do and just play with numbers until you get something that works.

Point of clarification for anyone that might miss this, it's the mass of the casing that provides brief confinement, not structural strength. No material is strong enough to make an iota of difference to a detonation wave, but inertia is a big factor on these time scales. Hence, while lighter, stronger materials are certainly available, they aren't helpful. Steel is a good compromise between providing enough mass, giving the bomb sufficient strength in transportation and handling, and being relatively cheap as casing material.

I'm just going to preemptively start working on an escape plan, because I know I'd be on the hit list. So add that to the whiteboard budget.

You need something separate for storage, but MHD generator can generate power from solar wind. Solar panel will give you way more power, though.

Sans reproduction, animal cells have inherently limited shelf life due to thermodynamics, chemistry, and background radiation (take your pick). Something is guaranteed to go wrong if you try to keep it up for astronomically significant times with overwhelming majority of neurons within the brain. Ability of neurons to be replaced is limited as is, but if you're going to have to recycle most if not all of them over the duration of the flight, keeping the brain in sleep is not an option. Without information updating as you replace neurons one by one, you'd be doing a hard wipe. And this is assuming you managed to get them to regenerate in the first place. So you could think to keep the brain in a slow dreaming state, allowing it to repair not just the cells, but also the information. And here we run into additional limitations of how the brain works, where we lose synapses over time as part of design. This is how we learn and how a lot of our memory works as well. If you allow that to keep happening, over astronomically significant time you'll end up with a senile old brain at destination at best, no matter how good your repair efforts are. And if you start repairing synapses, we're back to hard wipe scenario. This is why we have cryogenics as an idea. Keeping the brain at very nearly absolute zero would prevent any of these things from happening. Even effects of radiation will be limited. Albeit, you'll have to deal with accumulated radiation damage upon arrival somehow. Of course, all of the standard problems of cryogenics follow, not least of which are very strictly limited by thermodynamics. Alternatively, you could change how brain ages and repairs itself, as well as how it manages to hold on to information while retaining plasticity to learn new things. We'd have to do this if we want to attain anything like immortality, but we'd be literally redesigning human mind from ground up. Not only are we nowhere near even imagining where to start, but it also brings us into the depth of transhumanism of which it's very hard to even speculate. Unless we figure out FTL, people who will spread through the stars will not be human in any sense we think of it now. That's if we don't wipe ourselves out first.

I've not! I was actually unaware of that sharp drop in the speed of sound at SLD. I fully expected density to vary, and I would anticipate significant lensing because of it. However, so long as the scales involved are much greater than distances between ships, the sound should still propagate just as if it departed from false source. Same deal with bottom bounces, so long as there is sufficient depth. SLD throws the wrench into this, however. It's at just the "wrong" kind of depth, which is comparable or less than distance between the emitters, to interfere with phase array approach. Intuitively, I'd expect this to still work, considering three cases. Sub is in surface duct, and won't get anything useful from its sonars anyways due to all the reflections. Sub is in the shadow zone, and doesn't get anything useful. Or sub has direct path, and should see the false sources without any problems. What could be wrecking it is if some of the emitters are in the shadow, allowing the sub to get a bearing on true sources. I can't possibly do this in my head or even on paper, though. I might need to write a simulation to actually test this. I've been meaning to play around with DX12 RT API, and this could be an interesting use case for it. I'll see what I can come up with. Thanks for pointing it out! I had no idea sharp temperature drop on top of steady density increase produces such an interesting speed of sound curve.

A sonar system that only shows you false targets without showing you real ones seems properly disabled. But if you want to split hairs on terminology, I won't argue the point. Lets call it, "Creating decoys using hardware more commonly used for jamming." And the only limitations I'm setting is that subs don't talk to each other, and subs have a reason to rely on the sonar. You've provided me with the later in your previous two paragraphs, and I think we agree that subs communicating with each other would reveal them. So that's a real world scenario where this is useful. It might be that the sonar signature masking systems are good enough to where you wouldn't want to bother with this. I have no idea what the state of the art on these is. In that case, *shrug*. If there is no reason to jam, there is no reason to jam better. Can't argue with that.

Again, I don't honestly care about the specifics. If you can communicate to the sub from pretty much anything above surface, our entire discussion of sonar is irrelevant. We either assume there's a reason why such communication is impossible (ECM, destruction of other assets, etc.) or we don't bother with jamming, decoys, or any other means of throwing torpedoes off course. A sub that can receive a signal from anywhere else will know exact relative location of all relevant targets in the modern world, and the torpedoes can engage on inertial alone until they are in magnetic range. There is no way to fight that with any form of countermeasures available to the fleet short of taking out the sub before it's in range. Which is why these are two separate discussions. If you insist that communication will always be possible, then countermeasures are useless, and sub will only use its sonar to look for other subs. If your position is that this is the only way it can be, then our discussion of jamming or anything else the fleet might do is meaningless. In order to talk about jamming strategies, we have to be talking in context of the sub relying on them, which precludes communication with outside sources. Again, if you think that's unrealistic, that's fine. But it's a separate discussion. Typically, when you have a body that's mostly spherical, but not quite, the sensible thing is to decompose the bits that aren't into spherical harmonics. J2 is one of the relevant terms. You can see a bit more discussion about it in this Wikipedia article, for example. Indeed, most of the numerical models used have been developed for Earth's satellites and ICBMs, so that's the context in which I've learned classical perturbation theory as well. But all of the physics is essentially the same when applied to objects comprising the rings. It's because of their choice of the coordinate system. You can see that they have a special term for drag in the Z direction. The reason for this is quite obvious if you picture this from perspective of an object passing through the rings. The amount of drag will be almost zero for an object passing through along the motion of the objects within. But any object moving perpendicular to the rings will experience significantly more drag. All orbital elements are taken with respect to some datum. The choice is somewhat arbitrary, but the moment you break the symmetry, some choices end up much more convenient than others. When dealing with a ring system, taking plane of the ring as part of your datum just makes sense. Unfortunately, that particular paper doesn't really make a distinction, because they essentially restrict the discussion to equatorial rings. The math, however, is exactly the same. So long as you chose Z axis, such that drag in that direction is significantly higher, the inclination will tend to zero in that particular frame of reference. In other words, inclination tends to zero with respect to plane motion in which provides least resistance. Id est, the plane of prevalent motion in that particular band. If you're still uncertain, the crucial bit here is that drag has nothing to do with orientation of the planet. We're talking about drag with respect to environment of the ring, which is governed by initial orbital plane of the debris. You can tilt planet's axis relative to that any which way, and it doesn't change the math. The only place where planet's orientation starts to play a role is in precession as per eqs 19, 20.

Receiving what? We've already talked about it. If you have any source of information besides the subs in the area, you aren't even going to use your sonar to hunt surface targets. You have more reliable information, be it from surface ships' radars, aircraft, or satellite. Sonar is useless, and discussing jamming is pointless. If all you have to receive additional data from are other subs, I don't care if you want to insist that you can only receive on towed antenna, or suggest jury rigging the transmitters to send through it. The bottom line is that if you want to have subs share sonar data, you will give their presence away, regardless of which antenna you want to receive with and/or transmit with. Please, keep track of your own argument. If you want to drag radio into discussion, remember why you're doing it. Keeping in mind that majority of large moons are going to be in equatorial plane, making such rings far more likely. But yes, we could have ended up with a planet with inclined rings, and we didn't get any. As rare as they might be, some systems out there definitely have them. Also, I'd like to point out that the ring instability argument is absolute hogwash. Rings are very nearly circular, because anything in elliptical orbits will collide with each other. And the only effect on a circular orbit of the tidal forces from the planet is precession, which will be roughly uniform for the entire ring due to self-interaction of the objects comprising the ring (drag). So if you have multiple rings at different radii and inclinations, their relative orientation will change over time, but there is no force bringing rings to alignment with equator. Anyone who studied classical perturbation theory should know that. So again, there is absolutely nothing in orbital mechanics that would prevent stable inclined rings from remaining for a very long time once they are created. Even though initial formation of such rings is far less likely than these in equatorial plane. The second paper you've linked [this one] covers all of that. Specifically, the only non-periodic effect on inclination is dampening with respect to the plane of prevalent motion. (eq 13) In other words, inclination of particles tends to zero with respect to plane of the ring, not equator. Meaning the rings flatten, but remain otherwise stable in terms of inclination. The orientation of that plane drifts due to planet not being spherical. (eq 19, 20) This tells you that over time, the rings will precess around the planet. Note the R/a term, which tells you that different rings will precess at different rates. However, the damping forces discussed above, will keep each ring group intact. So even if you had just one plane in which rings were originally created, if they were spread over large enough distance, eventually they'll break down into multiple rings at different orientations, but common inclination angle. Could be quite an interesting sight.

You are conflating several things again. Lets split them up neatly into two scenarios. First, sub can receive messages from outside world. These can include locations of ships in enemy fleet. If fleet ECM aren't sufficient to prevent these, that's it, that's the end of discussion. The sub flat out doesn't need to use its sonar to look for surface targets and can engage them completely blind using satellite data. Now, lets suppose that you are cut off from communications from the surface for whatever reason, and you have to rely on sonars of the subs to hunt the surface ships. Jamming strategy is in place. Can communication between subs be used to cut through jamming? In theory yes, but anything you can use sub-to-sub is too short ranged and low rate. You can use the towable antenna to get a much stronger, higher rate signal across, that should be sufficient to link several subs together. But that signal is omnidirectional. The moment you start using towable antenna to send the signal, it will light up every console of the enemy fleet with unidentified contacts. That is how towable antenna gives you away. This isn't a strict requirements. However, most of the moons of a gas giant are going to form from the protoplanetary disk. Because of that, they share an inclination. The rings are formed either from leftovers of the same protoplanetary disk, or due to destruction of the moons. Moons can be destroyed either through collision or by entering planet's Roche limit. In either case, most of the debris ends up in the same plane as the protoplanetary disk used to be in. Of course, moons can, and often enough do, end up orbiting in completely different plains. This can be due to captures or various gravitational interactions. In either case, if one of these moons becomes destroyed, it can form a ring matching inclination of its original orbit. This would then allow for multiple ring systems with different inclinations orbiting the same planet. I'm not aware of any examples, but there is no reason why it can't happen.

Both. You want to jam passive and active sonar that may be employed by the sub or incoming torpedoes. The problem with jammers is that even if they can mask everything else, the source of jamming signal is too strong to hide in its own noise. You can always target source of such strong interference. The goal, therefore, is to present strong source points that don't correspond to physical locations of the ships. You get your all-masking noise, and anyone trying to target the source of the noise will hit nothing but empty space. (A dense grid can produce uniform, omnidirectional noise with nothing to target, but then your ocean surface is basically blanketed with ships, so that makes it kind of pointless. XD With discrete points, you have to have "hotspots" of noise, but they don't have to match locations of ships.) You might also be able to use it for your own detection. The pattern of the jamming noise is known to the source. You can actually use it as active sonar - in theory. I'd have to run numbers to see what the signal-to-noise is going to be like, and whether you can actually use it to look for subs while you're blinding them. Again, the advantage here is that you have a fleet that uses surface communication to network their jammers and sonars. But yeah, your ability to look for enemy subs is going to be greatly reduced at a minimum, and leaving you blind at the worst. Whether the advantages are worth it might depend on the situation. Can I guarantee detection within periscope range? *shrug* I'll have to run the numbers. That's definitely a good point. ELF won't be enough to break the above jamming strategy. You do actually need fairly high bitrate. The towable antenna would work, but it gives away subs. Not exact location, but presence for sure. I can see a group switching tactics the moment they spot multiple subs using surface communications. But yeah, if the sub is receiving anything from the surface, your game of hiding ships is basically up anyways. During cold war, when satellites had limited coverage, it was a different game. Today, any military that can hope to take on a supercarrier is going to know where every single one is at any given minute with sub-meter precision, and ELF has enough data rate to convey that for sure. Even though the sub can't get a GPS reading while submerged, the modern INS is precise enough to keep it within the sort of drift that will still let it put torpedoes within magnetic sensor range of a carrier without needing to see it. So unless you can prevent the sub from receiving data, decoys, jammers, and anything else you might try to throw off the sub is useless. If you allow it within torpedo range, you'll get hit. And here we'd have to talk about ECM and counter-ECM available, and I'd have to admit that I have no clue who has the edge. So... That definitely is a possibility. Jammers and decoys are still used. So it seems like there'd be some room for it. But they might be fallbacks for situations where everything else breaks down. With kinetic kill ICBMs, we might end up with no need for ship-hunting subs at all in the future. Any tactic, no matter how clever, can be superseded by another that just works better and is cheaper to implement.

Not at all, that's the whole point. Yes, I do need very precise locations of the jammers relative to each other. That would require additional hardware on the relevant ships. I'd go with VHF/UHF interferometers for that. They have wavelength comparable to acoustic, which ought to make positioning juuust right. Variations in water density will "move" false targets around, but it's the same effect that it has on sub's acoustics. That is, if you have density changes in the water, the target can always appear at the slightly wrong bearing than it really is due to refraction. That effect will be unchanged. With all of that in mind, I don't need to know where the sub is. The acoustic wave produced by the jammers is almost exactly identical to the wave produced by a single emitter if it was at false source' location. That's how holography works. Again, I can write out the exact numerical decomposition of the target waveform into waveforms that have to be produced by individual jammers. This is just mathematics. This means that regardless of where the sub is located, the sound will appear to come from a location selected by the system. One that does not correspond to location of any ship in the group. Now, the grid is discrete, and there are only so many ships you can have the jammers running on. That does create limitations. There can be additional "shadows" showing up in random spots, appearing as additional sources of interference. These are almost guaranteed not to correspond to locations of real ships either, but they are hard to minimize without having a periodic grid of ships. Second problem is that viewed from different angles, the false source location might be slightly different. If you had an entire grid of subs in communication, they would be able to use this to filter out the false locations and resolve true sources of jamming. But that's fundamentally impossible for the subs without revealing their location. As I've mentioned before, if you had that sort of linking capability, just feed locations of ships to subs from the satellite. This method explicitly produces a false target for the sub regardless of where the sub is located and is mathematically impossible to resolve to true sources of jamming for a single sub.

Latest incident puts question on Soyuz rocket, not the ship. Ship performed phenomenally, bringing the crew down safely despite failure happening at just about the worst possible moment. Granted, if the ruptured tank had actually blown, we could have had much sadder news, but like I said, it was a very bad timing for failure. All in all, safety of the ship is not questioned by ongoing investigation. Just that of the rocket. Given that, there is no reason not to send up MS-11 unmanned. Its a big expense and an even bigger financial risk if the rocket fails again, but leaving ISS unmanned is a greater risk. I think Roscosmos and NASA should bite the bullet and send MS-11 unmanned before MS-09 is due to return. If it makes it, jettison MS-09 and extend mission of the current crew. If it doesn't, have the crew come back down on 9, and take a risk with unoccupied ISS. It's not a great option, but it's the best one all around. The only other viable alternative is just to abandon ISS and hope it's still there when investigation concludes or Dragon and/or Starliner are ready for a manned mission. That's strictly worse than taking a chance with an unmanned launch right now. P.S. Strictly opinion.

That's like saying, I need to know where the eyes are going to be located to produce holographic image in front of the screen, hovering where no physical object exists. Yet a hologram certainly works, I hope you're not going to deny it. A phased array produces a signal that matches any desired pattern of waves, including these that match perfectly with any non-existent source within the area spanned by array, to within error permitted by density of an array. A carrier group has sufficient density to fool a single sub, regardless of where it is locating, to perceive false sources only and be blind to true sources of interference. This is fairly heavy math on top of very basic wave physics, and this has been known for well over a hundred years. I'm telling you that I can reproduce the exact sound that would be coming from an object at desired location, projected in all directions, with nothing at that location. This is tried and tested tech. You are telling me it's not good enough, because you believe in some magical ability of the sonar to know that there is nothing there, despite the actual sound wave reaching it being absolutely identical. I have read it. I'm sorry if my response wasn't sufficiently clear. We're talking about two completely different scenarios here. 1) I want to mask the fleet, hiding it entirely. I employ noise-canceling with an active array. You want to cut through it. You're looking for very specific, repetitive sound of an engine, impeller, or any other periodic noise, really, that you can lock onto. Given a slow scan of the beam, you'll eventually succeed, no matter how good my noise-canceling is. This is what I mean when you're looking for specific target in otherwise quiet background. 2) I want to mask locations of individual ships within a group, without giving you anything concrete to lock onto, under assumptions that you already know where the group is overall. I deploy jammers instead of noise-canceling, and network them to produce patches of high intensity in areas where no ship is located. You do not have a pattern to lock onto, because noise is inherently non-periodic. Any known sources of sounds coming from ships are greatly overwhelmed by omnidirectional background of noise. And yes, even if you have a beam, you will pick up a lot of noise from all directions when jammers are used. I hope you at least know that much. The reason you can still normally lock onto a jammer is because the beam will generally cut back some of the noise from directions other than directly from jammer. So while being jammed, what a sonar sees is noise and patches of more noise. Hence use of an array of jammers to create false sources of high intensity. So as you scan your beam, you'll see noise everywhere, with patches of it, that you believe to be jammers, at some locations within the group. These, however, do not correspond to any physical target. At this point you've already exhausted ability to steer the beam and to filter the signal, and they produce absolutely nothing. Short of employing active sonar, you're not going to get anything useful in this scenario. You don't understand the things you are claiming are relevant. I'm sure you know the specs. But if you don't understand how a phased array produces a signal, what kind of signal it can produce, and how specifically any number of beams can be produced from a single array starting at any point within the array, then I'm sorry to say that you don't understand how the sonar works either. Because a modern sonar is a phased array attached to a dome and any number of additional resonators with lots of additional processing on top. I don't know the specs of the dome. I don't know the arrangement of pickups or their relevant resonances. I don't know the software suit that goes on top of it. But none of that changes how it works. Only the quality of the signal you get and how narrow a beam you could make. And I'm telling you that an ideal device, with perfect reception, and beam as tight as physical dimensions of the dome can possibly allow, is insufficient to cut through this. So yes, that makes any technical details of an actual physical sonar, which will perform worse than this idealized sonar, absolutely irrelevant. It can't perform better because math. And if it performs worse, my argument is only stronger. If you feel that's good enough reason for you to smugly dismiss the whole argument, I won't stop you.

Yeah, and delay lines are precisely what allowed you to select a phase adjustment to signal received at each pickup, which lets you exclude everything but the beam you're interested in. It's like having a lens in front of the light detector, and rather than moving light detector, you change thickness of the lens to look in different directions. Interferometer telescopes work in exactly the same way, and they aren't classified. The advantage of working with sound or radio frequencies is that you can throw away the delay lines, record the signal with phase information intact, and then do any phase shifts you need in software. And that really gets us back to a phased array, with the difference that you need to correct for sonar dome shape, while giving you the signal strength of the full dome, rather than that of the array. I know you're probably read-in, so you can't talk about details regardless, but it's the kind of secret that isn't. At least, in broad strokes. I'm sure there are plenty of reasons to keep the details classified. I see where you're going with this, but still no. If you tune this to a bearing of a true source, you won't get any signal that's distinct from background noise, because you'll be getting noise from all the other sources hitting your pickups at just the right timings to travel down these delay lines and cancel out the actual signal from the source you're staring at. I could probably come up with a way to punch through this if we were looking for something very specific, like engine noise, while several sources produce fake engine noise, trying to project it to a false location. Alternatively, if there were at least a few subs that shared their raw acoustics data in real time, you could probably resolve true sources. But if we're staring at a bunch of jammers, your signal processing is already busy filtering out the noise, so you can try and locate sources of jamming signal. So the only place where the sonar's going to give you a signal that's distinct from background noise is if your beam is pointing at the false source. Looking at a true source will give you the same kind of noise as pointing in any other direction.