[1.1] RemoteTech v1.6.10 [2016-04-12]

[BigD145]

If it's orbital it slips. You can't get around that.

[Starstrider42]

While it may be outside of the scope of this mod, how hard would it be to make a mod that "maintained" the orbits of craft?

https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/115. One of the suggestions in the discussion is to make it a standalone mod so that things like KSPI can also use it.

[jebandhisfriends]

is it working with AIES 1.5.1 cominucations dishes ??

[Mecripp]

is it working with AIES 1.5.1 cominucations dishes ??

Try this https://dl.dropboxusercontent.com/u/72893034/RemoteTech_AIES_3.cfg

[AndreyATGB]

Orbital maintenance is a planned feature for Principia in the dev section, that's all I know about the subject. As for actually maintaining a network right now, I've never had issues. I had a 5 sat KEO network within 100ms of each other in orbital period (ion engines FTW) and they took a few years to start drifting apart. The problem is that once they start, the process is very quick and even then all that happens is they don't look like a nice pentagon anymore, the network is 100% functional anyway. I don't mind it enough to make me stop using these networks since all it takes is 10 minutes of my time to fix every 10-20 hours of gameplay.

[E.Nygma]

What I would like to see from the community, however, and I've asked this before, is examples of how your networks are set up at the moment. How many satellites do you use? How many dishes? Where are those dishes pointed? Most importantly, which part requires ongoing management? Knowing how RemoteTech actually gets used by the average player will help us improve the game rules much more than merely saying "RemoteTech requires juggling" as if it were obvious.

First of all, THANK YOU for continuing this awesome mod! :D

Second, Hello fellow Kerbonauts!

In response to your post:

I use a rather complicated satellite setup for Kerbin coverage:

1. 8 Satellites, octagonal formation, equatorial near-KSO, orbital period of 6:00:00:x hours
   
2. 8 Satellites, octagonal formation, polar near-KSO, orbital period of 6:00:00:x
   
3. 8 Satellites, octagonal formation, equatorial ~1500km orbit, orbital period of 3:00:00:x hours
   
4. 8 Satellites, octagonal formation, polar ~1500km orbit, orbital period of 3:00:00:x hours
   

All satellites are equipped with an Communotron 32 and 3 Communotron 88-88, pointing at AV, Kerbin and atm the Mun; I think for Minmus coverage I will launch additional relay satellites for the described basic coverage network

[BigD145]

Extreme coverage, but hey. Whatever network you want to place is your business. That would be a fancy GPS network.

[Hodo]

First of all, THANK YOU for continuing this awesome mod! :D

Second, Hello fellow Kerbonauts!

In response to your post:

I use a rather complicated satellite setup for Kerbin coverage:

1. 8 Satellites, octagonal formation, equatorial near-KSO, orbital period of 6:00:00:x hours
   
2. 8 Satellites, octagonal formation, polar near-KSO, orbital period of 6:00:00:x
   
3. 8 Satellites, octagonal formation, equatorial ~1500km orbit, orbital period of 3:00:00:x hours
   
4. 8 Satellites, octagonal formation, polar ~1500km orbit, orbital period of 3:00:00:x hours
   

All satellites are equipped with an Communotron 32 and 3 Communotron 88-88, pointing at AV, Kerbin and atm the Mun; I think for Minmus coverage I will launch additional relay satellites for the described basic coverage network

That is what I call overkill for satellite coverage. But it works, and I like it! Mine is a 5 satellite version of this, just polar and equitorial orbits.

[BigD145]

6 satellites in any form around any body is usually enough no matter the slippage. You might end up with a blackout once every 10+ years.

[E.Nygma]

Last time I had basically the same network configuration and after less than a year the sats desynced...

As for GPS: Just today I found the Figaro mod and was planning a new network, basic idea was ~50 satellites, but that's just for the drawing board

[Boomerang]

Even if you cheated, unless you never timewarp they'll eventually get out of sync anyway. This is very easy to see as your Ap and Pe change every time you do so. I'm not sure what its effects are on SMA and if they're the exact same for all sats, in which case it doesn't matter.

If you were referring to me, then if you never focus back on the vessels that you edit into 'perfect' orbits, there is zero drift over any timeframe. For example, after getting a KEO satellite into an orbit with a six hour period and an eccentricity as close to zero as I can reasonably get, then I'll edit the persistence file to read:

SMA: 3468750

INC: 0

ECC: 0

As long as I never refocus on that satellite, the floating point errors you describe don't happen because the craft is on rails. And in the event you do focus on the vessel, you can just re-edit the orbit. Because the dishes are already focused on wherever they need to be, there's really no reason to ever go back to the satellites anyway.

[VaporTrail]

A Mechjeb maneuver planner option to reach (or at least get close to) a specific set of orbital parameters (SMA, Ecc, Inc, Lan, W, etc...) would be nice... but getting the fine control necessary to do that is the issue. Mechjeb is great for rougher orbits, but anything that requires extreme precision it tends to overcontrol.

Something that puts a target up, allowing you to see where you need to burn with RCS (and how much dV is needed) would be nearly perfect. Once you get close enough to the desired orbit, drift is going to be a non-issue.

I just want to get away from using Hyperedit to set orbits on my power or comm constellations.

[Rayder]

Do flight computer instructions still disappear when you change active vessel? Now that manoeuvre nodes are persistent it would be nice to setup flight controls far in advance, then come back to the vessel when it's time to perform the burn.

[JDP]

Do flight computer instructions still disappear when you change active vessel? Now that manoeuvre nodes are persistent it would be nice to setup flight controls far in advance, then come back to the vessel when it's time to perform the burn.

Yep they do. There is a feature suggestion on github to add it though, Issue#32

[Drew Kerman]

I gotta say some of these networks are a bit over-engineered. There's really no need for more than 3 satellites over any body in the Kerbol system with exception of Jool and Kerbol (for local orbital operations). And going all the way out to KSO orbit is also unnecessary. That said, building massive networks can be fun, challenging and an excuse to build awesome large rockets and satellites! So I don't mean to say people doing it this way are doing it wrong. But if you like efficiency (and are role playing with finances in career with limited parts), then here's my proposal:

Say I'm setting up a constellation of 3 satellites over Kerbin and want them to have Line of Sight over Kerbin's atmosphere (670km measured from center of Kerbin) and be in range of the Communotron16 omni (2,500km). First let's make sure this is even possible using the incircle of a triangle. Plug in 2500 for each leg and we get 721km, which is larger than 670km so we're good, but we don't want to be at max range so let's lower our distance for some wiggle room. 2350km between each satellite will put the signal 8km over Kerbin's atmosphere. Cool, now we just get our orbital altitude with the circumcircle of a triangle. If you pop in 2350 for each leg you'll get 1,357km, but don't forget we need to subtract from that Kerbin's radius of 600km to get a target altitude of 757km. Now you have two options - You can launch three at once and drop them from a carrier ship, or launch them one at a time.

Something that puts a target up, allowing you to see where you need to burn with RCS (and how much dV is needed) would be nearly perfect. Once you get close enough to the desired orbit, drift is going to be a non-issue.

This is doable without any additional tools. After the first ComSat is on a circular 757km orbit, you launch/deploy your second into 757km circular orbit and target the first and then use the maneuver nodes to adjust your orbit until you have an intercept with the target at the distance you need them to be. Then you burn to adjust your orbit, and after one orbit you re-circularize and are in position. Launch and do the same with your third. Done.

RCS burn calculations can be done with this equation. Just pop in the thruster ISP (usually 260 for RCS but be sure, I have some thrusters that are 270), your craft mass (VOID gives you this to three decimal places) and the delta-v required for the maneuver (PreciseNode gives you this to two decimal places). It is extremely accurate. I have a HOTAS setup so KSP never gives me accurate burn times using my throttle and I have to manually calculate all my burns. This equation never sent me wrong. If you end up having to only thrust for 2-3 seconds I would recommend shutting down half of your RCS jets and switching on fine-control. The longer the burn the better control you will have. Also, TweakableEverything will give you the ability to thrust-limit your RCS jets for even more fine control.

Then, as mentioned earlier, you throw up two satellites with long-range dishes into polar orbits, one going high above the ecliptic, one going low below, and you have good coverage for interplanetary comms.

[AdmiralTigerclaw]

I gotta say some of these networks are a bit over-engineered. There's really no need for more than 3 satellites over any body in the Kerbol system with exception of Jool and Kerbol (for local orbital operations). And going all the way out to KSO orbit is also unnecessary. That said, building massive networks can be fun, challenging and an excuse to build awesome large rockets and satellites! So I don't mean to say people doing it this way are doing it wrong. But if you like efficiency (and are role playing with finances in career with limited parts), then here's my proposal:

Say I'm setting up a constellation of 3 satellites over Kerbin and want them to have Line of Sight over Kerbin's atmosphere (670km measured from center of Kerbin) and be in range of the Communotron16 omni (2,500km). First let's make sure this is even possible using the incircle of a triangle. Plug in 2500 for each leg and we get 721km, which is larger than 670km so we're good, but we don't want to be at max range so let's lower our distance for some wiggle room. 2350km between each satellite will put the signal 8km over Kerbin's atmosphere. Cool, now we just get our orbital altitude with the circumcircle of a triangle. If you pop in 2350 for each leg you'll get 1,357km, but don't forget we need to subtract from that Kerbin's radius of 600km to get a target altitude of 757km. Now you have two options - You can launch three at once and drop them from a carrier ship, or launch them one at a time.

This is doable without any additional tools. After the first ComSat is on a circular 757km orbit, you launch/deploy your second into 757km circular orbit and target the first and then use the maneuver nodes to adjust your orbit until you have an intercept with the target at the distance you need them to be. Then you burn to adjust your orbit, and after one orbit you re-circularize and are in position. Launch and do the same with your third. Done.

RCS burn calculations can be done with this equation. Just pop in the thruster ISP (usually 260 for RCS but be sure, I have some thrusters that are 270), your craft mass (VOID gives you this to three decimal places) and the delta-v required for the maneuver (PreciseNode gives you this to two decimal places). It is extremely accurate. I have a HOTAS setup so KSP never gives me accurate burn times using my throttle and I have to manually calculate all my burns. This equation never sent me wrong. If you end up having to only thrust for 2-3 seconds I would recommend shutting down half of your RCS jets and switching on fine-control. The longer the burn the better control you will have. Also, TweakableEverything will give you the ability to thrust-limit your RCS jets for even more fine control.

Then, as mentioned earlier, you throw up two satellites with long-range dishes into polar orbits, one going high above the ecliptic, one going low below, and you have good coverage for interplanetary comms.

Yes, a lot of the examples are over engineered. But then again, some people are accounting for gap redundancies because of the drift. I myself use a two-ring LKO and KEO configuration matched with a very high orbit command station. (Or did. I try that now with ECLSS, I'll have six dead kerbals before long.)

[Dunbaratu]

I just started trying to use RT2 and I can't make any sense out of the instruction manual. The thing that seems missing is just the simple "what button does what" with the flight computer panel.

If I launch an unmanned vessel to the launchpad and want to tell the flight computer to just do one simple instruction like:

20 seconds from now, start aiming north, pitched up 85 degrees, throttle at 100%, and burn like that for 60 seconds.

I can't figure out what buttons I'm supposed to hit in what order to queue up that instruction.

First off, no matter what I type into the "delay" box, the command seems to start immediately as soon as I hit stage 1, ignoring the delay I typed in.

Secondly, no matter what I type into the pitch/hdg/roll boxes, the command still always says "Target: None".

I clearly don't get how the UI works, and I can't find the instructions for it anywhere in the manual webpage.

[Drew Kerman]

Yes, a lot of the examples are over engineered. But then again, some people are accounting for gap redundancies because of the drift

Drift is, IMO, a non-serious issue overall, if your network is simple enough. You can use RCS and fine-control setting to match up orbital periods to within a few tenths of a second. It's been 3 earth months in the game since I last adjusted orbits of my Kerbin LKO network (set up as described above) and they can all still see each other fine - I did not use hyperedit or save file editing to change their orbits, just RCS and VOID to get their orbital periods close. So eventually they will drift out of line of sight. Within the next month or two of game time I plan to re-position them again. This process will simply involve two of the three satellites and I will use the targeting method to adjust first one and then the other. Then I'll be good for another few months. If ever there is a worry about losing a comm linkage during a mission, any adjustments to the network can be done prior to the mission. Obviously the more satellites you put in your network that depend on a set position to work, the more of a problem drift will become, which is another reason I like to keep things simple

Edited July 1, 2014 by Gaiiden

[AndreyATGB]

I just started trying to use RT2 and I can't make any sense out of the instruction manual. The thing that seems missing is just the simple "what button does what" with the flight computer panel.

If I launch an unmanned vessel to the launchpad and want to tell the flight computer to just do one simple instruction like:

20 seconds from now, start aiming north, pitched up 85 degrees, throttle at 100%, and burn like that for 60 seconds.

I can't figure out what buttons I'm supposed to hit in what order to queue up that instruction.

First off, no matter what I type into the "delay" box, the command seems to start immediately as soon as I hit stage 1, ignoring the delay I typed in.

Secondly, no matter what I type into the pitch/hdg/roll boxes, the command still always says "Target: None".

I clearly don't get how the UI works, and I can't find the instructions for it anywhere in the manual webpage.

I'll load up my test game and input those for you since it's easier than typing here.

As for delay, you need to hit enter after you write it, then it'll work.

Here's what I think you want:

Keep in mind that as far as I know, there's no way to simply queue commands without executing instantly so I had to put in the launch to start after 1 minute so I have time to input everything else. Really the flight computer isn't made for these kinds of things, it's made for deep-space manuevers where you have minutes of delay and thus cannot actively control the vessel. You should launch yourself basically and only use the computer for node executions long after Kerbin SOI.

Edited July 1, 2014 by AndreyATGB

[AdmiralTigerclaw]

Drift is, IMO, a non-serious issue overall, if your network is simple enough. You can use RCS and fine-control setting to match up orbital periods to within a few tenths of a second. It's been 3 earth months in the game since I last adjusted orbits of my Kerbin LKO network (set up as described above) and they can all still see each other fine - I did not use hyperedit or save file editing to change their orbits, just RCS and VOID to get their orbital periods close. So eventually they will drift out of line of sight. Within the next month or two of game time I plan to re-position them again. This process will simply involve two of the three satellites and I will use the targeting method to adjust first one and then the other. Then I'll be good for another few months. If ever there is a worry about losing a comm linkage during a mission, any adjustments to the network can be done prior to the mission. Obviously the more satellites you put in your network that depend on a set position to work, the more of a problem drift will become, which is another reason I like to keep things simple

This is not a desirable task to have to perform for most players. Having to personally go in and upkeep the constellation becomes a tedious chore that interferes with overall gameplay. You may not find this troublesome and find fixing the constellation 'simple' to execute. But many other players do. And despite your comments otherwise, drift is a very hefty concern. Enough that there's even an open issue discussing ways to 'lock' constellations together once they've been established. Station keeping is an automated task, and players shouldn't be forced to personally go in and micromanage every sat they have every few in-game months. It falls under my principle of 'set it and forget it' concerning one player simulating the tasks of thousands of people.

[Drew Kerman]

point conceded

[Aedile]

Yes, a lot of the examples are over engineered. But then again, some people are accounting for gap redundancies because of the drift. I myself use a two-ring LKO and KEO configuration matched with a very high orbit command station. (Or did. I try that now with ECLSS, I'll have six dead kerbals before long.)

Generally speaking you need 3 sats (their altitude should be at least the planet's radius, but the closer you are the more precise you'll need to be), as long as you have antenna with long enough range. Drift is easily avoidable, all you need is to have same period (semimajor axis), and inclination. This is a bit more difficult to achieve on low gravity worlds (Gilly is almost impossible even without signal delay). However since they are smaller, they allow for pretty big drift, also since drift happens each orbit, slower orbits will drift slower. A 3 sat on 750km over Kirbin can easily stay in sync for at least 60 years. If you have signal delay on, you probably will need a few extra tools, such as precise node. You will likely need control station or kOS for such a precision on other planets, or just a manned misson to deploy each sat.

Same applies for stationary sats. Even though they won't be strictly stationary, as long as your inclination is around 0, and your period same as the planet, you'll be fine. They are much more difficult to keep on place though, as the inclination will cause drift. Haven't found any particular use of these to be honest.

The easiest way to deploy them, is do all 3 in the same mission. Get in desired "circular" orbit. Deploy one. Get the mothership on eccentric orbit in such a way, that after 1 or 2 orbits, you'll be on the needed angle. You can do this with a node, paying attention to the distance. Decouple the other 2. Wait for position, circularize second orbit, wait, circularize third. What is important is your period, orbits needn't match, other than the inclination.

You need 2 dishes to each moon/planet to connect different sat systems. 2 of the three sats will be visible at any time (provided third body is not between), so at least one of the dishes will connect.

The time you need more than 3 sats is too big body (eg. jool/kerbol), or bodies with atmosphere. Most omni antennas will break under high dynamic pressure, so you'll probably need more than 3 for eve/kirbin/laythe landing probes/planes. You'll need quite a constellation in fact. I have found that adding one of the unbreakable dishes to your craft is much better solution.

Easiest way for interplanetary communication is solar orbit close to the planetary one, but apart from kirbin, this is not particularly easy to accomplish. Eccentric polar orbit with Pe at one of the poles works pretty good as well.

In any case, you might want some redundant connections, in case other planets/moons come in between, and most notably kerbol. You are best off with control stations (easily accomplished even with LS mods), so only blackouts you'll generally get will be relevant to science transmissions.

[Rayder]

The problem is at this stage, I don't think anyone is aware of a constellation that:

1. Is relatively simple

2. Provides complete coverage of a body (particularly interplanetary)

3. Requires no maintenance, and

4. Has zero downtime.

I have a system in mind that currently provides 100% uptime to any body and requires no maintenance. But I'm stuck at providing 100% coverage on the body's surface. The connection between planets is easy enough.

But getting a connection to anywhere on the surface seems a bit tricky. At least in a way that is simple and requires no maintenance. At this stage I'm thinking of three highly elliptical orbits that are 120 degrees apart. It's not 100%, but at least when it goes dark the satellite uplink should come back fairly quickly.

[Aedile]

This is not a desirable task to have to perform for most players. Having to personally go in and upkeep the constellation becomes a tedious chore that interferes with overall gameplay. You may not find this troublesome and find fixing the constellation 'simple' to execute. But many other players do. And despite your comments otherwise, drift is a very hefty concern. Enough that there's even an open issue discussing ways to 'lock' constellations together once they've been established. Station keeping is an automated task, and players shouldn't be forced to personally go in and micromanage every sat they have every few in-game months. It falls under my principle of 'set it and forget it' concerning one player simulating the tasks of thousands of people.

There are 2 reasons where you'll lose connection. The planets breaks it, or antennas are out of range. Using long range omni antennas allow for considerable amount of drift. The 5000km antennas placed on satellites at 2000km around kirbin, will allow for quite large drift before they get blocked (some 40 degree, from the intended position), and the third sat will connect them even then. You'll start losing coverage when all 3 sats are (almost) at the same side of the planet.

So no, not a big problem, if you set up things correctly. But yes you need to either do some math (if ap+pe is same for your sats they shouldn't drift by much) , or use something like KER VOID or MJ to tell your period/semimajor axis

If your sat is superlight, I suggest using the single thruster rcs (its front one back), it's really easy to mess up your perfect orbit turning around.

[AdmiralTigerclaw]

There are 2 reasons where you'll lose connection. The planets breaks it, or antennas are out of range. Using long range omni antennas allow for considerable amount of drift. The 5000km antennas placed on satellites at 2000km around kirbin, will allow for quite large drift before they get blocked (some 40 degree, from the intended position), and the third sat will connect them even then. You'll start losing coverage when all 3 sats are (almost) at the same side of the planet.

So no, not a big problem, if you set up things correctly. But yes you need to either do some math (if ap+pe is same for your sats they shouldn't drift by much) , or use something like KER VOID or MJ to tell your period/semimajor axis

If your sat is superlight, I suggest using the single thruster rcs (its front one back), it's really easy to mess up your perfect orbit turning around.

The point you are failing to understand is that your solution is not something every player can or will do. Either from inadequate knowledge, such as either not understanding the mechanics or the math. Or from not wanting to go into THAT much detail in orbital drift mechanics to tune it to a knife's edge.

I understand there are super low drift satellite constellations if you do everything perfect and put a lot of time and effort into it. But you are neglecting to realize that the player base for this mod is ALREADY strapped for understanding of how to do these things to this level of precision, or are unwilling to expend that much effort. You don't need to explain to me in rigorous detail HOW to do it. I know how to do it already. But the problem isn't knowing how to do it, it's whether one feels it is worth the expended effort to do it if they also know they'll have to tweak it, no matter how long down the line. Yes, it may drift over a longer period of time than most orbits, but when it comes time to 'fix' the phase angles, does the player really want to drop whatever else they're doing to do a tedious maintenance task?

It's the dividing line between what is fun, and what is retentive tedium that becomes the problem here. I could, with some work, likely get my constellation into lockstep like a champ. I did it once before just to prove to myself it could be done, but it's not something I want to have to make a routine side task. Why would I force other players to do this?