Jump to content

RCgothic

Members
  • Posts

    2,893
  • Joined

  • Last visited

Everything posted by RCgothic

  1. Molniya orbits have a specific use - quasi-stationary above a particular surface location at high latitudes. They're similar to geostationary orbits, where you want to minimise the amount that your surface-based dish has to move. Point at a particular patch of sky and there'll always be a satellite there. Let's discuss these two orbits a bit: Geosynchronous Orbits Geostationary orbits (or Geosynchronous Equatorial Orbits: GEO) acheive this by matching the orbital period to the earth's rotation in a circular orbit. Because a geostationary satellite is exactly over the equator it remains perfectly stationary from the earth's reference frame and your surface dish therefore doesn't need any off-axis or tracking capabilities. They also remain perfectly stationary with respect to each other, which simplifies sat to sat communications, making global relay networks simpler. However there are a couple of disadvantages. Because they have to orbit at a specific height very closely, and because there's a minimum spacing between satellites before you start to get radio interference, there are only so many satellites that can operate in GEO. Yes, countries and corporations actually have arguments about this, and there's an international body that mediates. Secondly, for countries in high latitudes to point your dish at a satellite in GEO means pointing it at or near the horizon, which is very bad for reception because you start picking up ground-based interference. Molniya Orbits You can't get a satellite to hover over a high latitude in a circular synchronous orbit. Inclined orbits must necessarily cross the equator, which means your satellite will disappear below the horizon frequently. Worse, it moves rapidly across the sky, meaning you have to track it with your dish. It also shares an orbital height with sats in GEO and thus takes up a slot. Molniya orbits attempt to solve a couple of these problems for high latitude applications. Because satellites in eliptical orbits move more slowly near apoapsis, if you place them in a highly eliptical orbit they spend most of their time in the higher part of their orbit. Orbits don't need to be circular to have a period of 24 hours, so you can place them in a highly eliptical inclined orbit and they will appear to 'dwell' over a particular surface location at the same time each day, which means your surface dish can again be pretty simple as long as you're prepared to wait. Or you can discard the 24h requirement and have several sats in still more eliptical orbits. You won't get the same satellite at the same time each day, but as they're further away each satellite will spend even more time in an even smaller area of sky, and by the time it's leaving your area of reception another will be entering it. There are also any number of these orbits, so bandwidth slots are far less restricted. There are a couple of drawbacks to molniya orbits (as might be expected). Because they go much further away, they require more signal power and bigger dishes to communicate with. Secondly, because the orbits are not circular it's much harder for satelites to stay in contact with each other as the angles between them change wildly over the course of an orbit. Note: For mission control, having a satellite with a high dwell time isn't a huge problem, because you can just invest in a dish that can track it and hire ground stations over the horizon for when you can't see a satellite directly. Dwell time becomes much more important in commercial applications. 100,000 trackable dishes, paid for by households? GEO and Molniya suddenly look much more attractive. KSP Anyway, in KSP even Remote Tech does not model dish orientations, with each dish having perfect 360deg tracking. Tell a dish it's trying to point at KSP, and as far as it's concerned it actually is, no matter that it's physically pointing at Jool at this instant and the angle to KSP is changing at 25deg/s. It is thus highly unlikely that any stock solution will concern itself with which way dishes are pointing. It's a level of difficulty too far for most casual players. So in KSP we don't have to deal with dish orientation/tracking, and we're not trying to reach 100,000 households with simple dishes. There's just no need outside of a specific contract to put a satellite in KEO or Molniya. They're not more useful than any other orbit. Me, Personally When playing with Remote Tech, I use a network of 3 sats at approximately 800km altitude. This gives them enough line of sight over the horizon to allow them some margin for error for phase angle and phase angle drift. In actuality, they go in an orbit with an orbital period of a round number of minutes and a 5/6th orbital period that is also a round number of minutes. They aren't in stationary orbits, but they don't have to be. All dishes in this game have perfect tracking. I use Excel to work out the target orbital height/period and KER to match those in game. I launch three sats on the same launcher to the target apoapsis and 5/6th orbital period. I detach one sat and use its on-board monoprop to circularise. I like my sats heavy, but with loads of RCS they circularise pretty easily. Two orbits later the launcher has fallen 1/3 of an orbit behind (because 5/6 period!) and I detach and circularise a second relay at apoapsis. Two orbits later I do the same thing again. Finally, I disable most of the onboard RCS, and use just one or two thrusters and fine-control mode to exactly match orbital periods using KER. These usually don't end up being perfectly circular! That's far too much of a pain. There may be 100m or so between apoapsis and periapsis. It's only the orbital period that matters and usually I get them down to 0.01s per orbit, which is enough to keep them in phase for ages. High mass/low thrust help do this accurately. Maintenance-free relay network! And even if they do fall out of phase, just deboost the offending sat into a fractional orbit for a few rotations before circularising and fine-tuning again. But I've never actually had to do that yet. Expanding the network is a variation on this theme.
  2. So apparently I missed the update to inflict reputation penalties for declining contracts due to sandboxing for 1.0.5. I'd been wondering why my reputation was going negative my new career game.
  3. Jettisoning engines is not Single Stage To Orbit, btw.
  4. I've between trying to do this recently. Building in safe abort modes is a cool challenge. But having an EVA glitch whilst on 4x warp kill Jeb was most unwelcome.
  5. And now I've killed Bill. That's the first time I've burnt up on ascent! Time to start over again I think.
  6. Oops, killed Val already. Forgot suborbital could be deadly.
  7. Landed on and returned from Duna for the first time!
  8. 1093m/s. Beacon assisted parking brake. Sepratrons have the best twr. This was built for a challenge thread, and was briefly the challenge leader before being overtaken. The trick is keeping it in a straight line, which is basically just luck. @tewpie managed >1200m/s before the end of the runway.
  9. Best I can find at short notice. The three small polar orbits do the job. Walker Star 18/3/1 in 89deg inclined orbits (evades the polar krakens). The higher constellations are for orbital/interplanetary stuff. Six sats is enough for ground or orbital operations between deployable antennae, but for re-entry or low-level supersonic stuff 18 keeps the basic indestructible antenna in range.
  10. Is it possible to implement sub-networks? I've picked up this bad habit of providing total surface coverage so I never lose contact with low-level probes. In my defence I can only say that this mod makes satellite networks fun enough to want to! For Kerbin this requires 18 sats, and it only gets worse from there. As the number of relays increasing exponentially increases pathfinding complexity, it would be useful to limit the number of possible paths. E.g.: An antenna is placed in custom group "Duna Rovers". It is allowed to talk to group "Duna Surface Relays", and is only allowed to check links to that subgroup. It can't talk to other Duna Rovers, or try to connect to Kerbin. Let's say I have 5 Rovers. "Duna Surface Relays" form a network (6) in low orbit. They're allowed to talk to "Duna Rovers", "Duna Surface Relays" and "Duna Interplanetary", possibly through multiple antennae if the user interface would otherwise be too complex. "Duna Interplanetary" is a high orbit network of 3 high-power sats. It can talk to "Duna Surface Relays", "Ike Surface Relays (3 relays)", "Duna Space (4 non-non-comm probes, only allowed to talk to interplanetary)" and "Kerbin Interplanetary (3 relays)". "Kerbin Interplanetary" connects directly to KSC and "Duna Interplanetary". Additionally there's 1 "Ike Rover" which talks to "Ike Surface Relays". Assuming that's it, total 26 craft. Now I'm not great at combinatorics, but that's 325 possible connections between relays and 26! (~4e26)possible non-cyclic paths between two nodes that need to be checked for connection to KSC? I'm sure RT is smarter than that, but still. The proposed subnetwork implementation would have the following connections: 1 Duna Rover (1)-> Any Duna Relay (6) =6 paths Any Duna Relay (6) -> Any Duna Interplanetary (3) = 6480 paths Ike Rover (1) -> Any Ike Relay (3) = 3 paths Any Duna Interplanetary (3) -> Any Ike Relay (3) = 45 paths Any Duna Interplanetary (3) -> Any Duna Space (4) = 20 paths Any Duna Interplanetary (3) -> Any Kerbin Interplanetary (3) = 45 paths Kerbin Interplanetary (3) -> KSC = 6 paths. This gives 6*6480 ways to go from duna rover->duna relays->duna interplanetary. = 38880. From duna Interplanetary there are 155 ways to go down a dead end (to duna space or Ike) and 45 paths back to Kerbin. Once at Kerbin there are 6 other options. Total routes: 38880*(45*6+155) = ~16 million paths. That's a vast improvement over 4e23. I'm sure I've miscounted somewhere, or maybe RT is already that clever, but it would knock a pretty substantial overhead off and more closely replicate real satellite networks too. I really don't mean this to come across as a feature demand, more just making a suggestion and sharing some thoughts. :-)
  11. Docked two fuel modules behind my Duna mothership, and two Ike landers to each side. I didn't need two, but hey, keeps things balanced. Only the crewed duna spaceplane to go! May just be a conventional lander if I'm not feeling ambitious. Also, does anyone know how to stop the aerodynamic forces overlay each time I take a screenshot? Is it easier to change KSP's shortcut to something else or would it be easier to change it in Steam?
  12. And today I failed to assemble my revised Duna mothership because I'd put the lower docking port seniors on backwards. Kept nudging the core stage into it's fuel tanks and wondering why they wouldn't dock!
  13. Today I failed to double-dock my Duna mothership's fuel tanks. Without a double dock they were far too flimsily connected, so I implemented Abort from LKO. My untested Duna spaceplane successfully re-entered, but didn't have enough pitch authority to keep the nose up. It became clear that a return to KSC was not on the cards, and the plane shortly ditched into the ocean at 45deg and 50m/s. I'm pleased to report that Jeb, Bill, Bob and Val were all recovered safely.
  14. If you're talking about pitching up during atmospheric flight it could be that your centre of mass is moving as fuel burns. That will affect the trim of your aircraft.
  15. Well done! I knew all Sepratrons was the way to go. How many did you use, and how did you for them all inside that structural fuselage?
  16. I couldn't beat ElMenduko, but you guys have the right of it. I managed a new personal best: [URL=http://smg.photobucket.com/user/rcgothic/media/2015-11-17_00001_zpsqcskhr0w.jpg.html][IMG]http://img.photobucket.com/albums/v723/rcgothic/2015-11-17_00001_zpsqcskhr0w.jpg[/IMG][/URL] [B]1092.4m/s [/B] The Vector does all right on starting TWR. It plus a full tank for the runway is 6.25t and gives you 1000kN thrust. 6.25t gets you 90 Sepratrons though. That's 1250kN of thrust ASL. Which considering you need to bring along extra support for them and they cause additional drag is not much difference. Until you burn through all that fuel. The Vector dry still weighs 4.25t. The Sepratrons weigh just 0.9t. Dump the Vector, it's not contributing. I couldn't make a craft with 90 functioning Sepratrons on it. I couldn't keep it stable, undetonated, and pointing in the right direction. But I bet whoever does manage it will get a new high score.
  17. I have one more idea. I'll try it this evening if the headache goes away.
  18. I managed to squeeze an extra 1m/s out of it by adding a ridiculous quantity of engines. (>100 sepratrons?) , but I think this is the best I can do: [URL="http://smg.photobucket.com/user/rcgothic/media/2015-11-16_00022_zpsv4ynrsch.jpg.html"][IMG]http://img.photobucket.com/albums/v723/rcgothic/2015-11-16_00022_zpsv4ynrsch.jpg[/IMG][/URL] 1010.1m/s
  19. I think this was an even better run, but the screenshot wasn't perfectly timed: [URL=http://smg.photobucket.com/user/rcgothic/media/2015-11-16_00017_zpsy1qaxcso.jpg.html][IMG]http://img.photobucket.com/albums/v723/rcgothic/2015-11-16_00017_zpsy1qaxcso.jpg[/IMG][/URL] 1009.1 m/s
  20. I started from well after the start of the runway though if we're being that picky.
  21. Smashed it. 1010.5 m/s [URL="http://smg.photobucket.com/user/rcgothic/media/2015-11-16_00004_zpskcsmgbwz.jpg.html"][IMG]http://img.photobucket.com/albums/v723/rcgothic/2015-11-16_00004_zpskcsmgbwz.jpg[/IMG][/URL] [URL="http://smg.photobucket.com/user/rcgothic/media/2015-11-16_00003_zpsrdw98ebt.jpg.html"][IMG]http://img.photobucket.com/albums/v723/rcgothic/2015-11-16_00003_zpsrdw98ebt.jpg[/IMG][/URL] That's a crash into the final light, so it's exactly at the end of the runway.
  22. I managed to get this 1111.3t beast in the air: However I don't think there's any chance I'll be landing it:
×
×
  • Create New...