[0.20] RemoteTech: Relay Network – V 0.5.0.1

[Biwin]

Hey I've been using remote tech for a couple weeks now, and suddenly the other day it went totally wonky on me. The compatibility patch stopped working altogether and I can no longer send or receive signals from stock parts. Also, my satellites stop receiving signals from KSC the instant I decouple them from the manned ship that takes them to their geostationary orbit, meaning if I want to set up my satellite net I have to leave a poor kerbal with each satellite. I tried reinstalling the compatibility patch to no avail.

Any ideas?

[Blu_C]

Have a question for RemoteTech 2.

Was there a change that limits how many times the signal can be bounced to reach a satellite? I ask because I've been trying to set up a Com array around Kerbin and have been noticing odd things with satellites being out of contact when I think they should have signal.

Some details: I'm setting up the network at ~500km above Kerbin and have been careful to ensure that the satellites have all been dropped off with an orbital period of 1h4m15s to ensure that there is a minimum of drift. Because these are supposed to be cheap satellites for only bumping the signal around the planet before a longer range relay shoots it farther away these only carry cheap omni-directional antennas (the 5.0 Mm ones) which I determined should have more than enough range for all my kerbin orbit operations.

In spite of this satellites that are on the far side of Kerbin remain out of contact. I've looked at the signal pathways being generated and it seems like the signal no longer gets passed along after 2 bounces, even if another satellite is theoretically in range. Sometimes it will even show a link to said satellite, though instead of a thick green line it will be a narrow brown one (which I suspect simply indicates a link with no path to a Command station). Can provide images if necessary, but it feels like I'm missing something painfully obvious.

[Dappa]

Have a question for RemoteTech 2.

Was there a change that limits how many times the signal can be bounced to reach a satellite? I ask because I've been trying to set up a Com array around Kerbin and have been noticing odd things with satellites being out of contact when I think they should have signal.

Some details: I'm setting up the network at ~500km above Kerbin and have been careful to ensure that the satellites have all been dropped off with an orbital period of 1h4m15s to ensure that there is a minimum of drift. Because these are supposed to be cheap satellites for only bumping the signal around the planet before a longer range relay shoots it farther away these only carry cheap omni-directional antennas (the 5.0 Mm ones) which I determined should have more than enough range for all my kerbin orbit operations.

In spite of this satellites that are on the far side of Kerbin remain out of contact. I've looked at the signal pathways being generated and it seems like the signal no longer gets passed along after 2 bounces, even if another satellite is theoretically in range. Sometimes it will even show a link to said satellite, though instead of a thick green line it will be a narrow brown one (which I suspect simply indicates a link with no path to a Command station). Can provide images if necessary, but it feels like I'm missing something painfully obvious.

Known bug.

[WinkAllKerb'']

Hello, Not tested yet as i m still discovering KSP but definetely in my TOP five most wanted feature. Can wait for a full version ;o)

[Blu_C]

Known bug.

I will now go sit down and have a sad.

[Nachtwind]

Just testing RT2 here but i dont know if it an error or not. I assambled a simple probe core to a few antennas and packed one that can be used in a non-deployed state. All that is connected to power, some rockets and all else you need to reach orbit.. in theory.

So my problem is, that the throttle "jitters" and completly ignores manual input whatsoever. I also cant seem to move the craft when launched (via Mechjeb)..

There is a connection available to the KSC and it shows a delay.. so i suppose that stuff works..

Any ideas?

[DoubleOSeven1]

Just testing RT2 here but i dont know if it an error or not. I assambled a simple probe core to a few antennas and packed one that can be used in a non-deployed state. All that is connected to power, some rockets and all else you need to reach orbit.. in theory.

So my problem is, that the throttle "jitters" and completly ignores manual input whatsoever. I also cant seem to move the craft when launched (via Mechjeb)..

There is a connection available to the KSC and it shows a delay.. so i suppose that stuff works..

Any ideas?

This is a Known Bug

[Diche Bach]

I hate to say this, and I don't know if switching to RT2 would fix things for me . . but I'm just not getting the hang of this Flight Computer, which is making getting a geosynch commsat very problematic. The main problem I'm having that doesn't boil down to just simple errors in keystrokes is that

1. When I queue a delayed burn, it burns. But by the time my ship has orbited around to the position for the burn, the actual position of the blue node vector marker seems to have moved relative to where it was when I set up the burn node.

2. As a result, I keep causing my orbits to get more elliptical and with apoapsis much bigger than my target for my penultimate burn (~2860ish km).

The other thing that is weird, it seems like the ship does NOT orient onto the blue vector marker on its own accord the way it does in JDP's video (perhaps this was a feature added in RT2?). Instead it just burns in whatever direction it is facing.

Add to this that, the exact order in which you: setup a node; turn to align on the blue marker; stop all motion, turn off SAS (having it on when you open the Flight Computer seems to cause the delayed burn to not occur, at least sometimes), open the Flight Computer (I find it must be in this order else the Flight Computer won't work right), type in your burn Dv and delay, hit Maneuver; is rather challenging to execute and any deviation from this order seems to cause the delayed maneuver to fail.

Should I install RT2? Is that likely to fix this stuff?

Is it possible Mechjeb 2.09 is messing things up? (I understand that the stock command pod overwrites from MJ 2.09 are not using the 0.21.1 KSP SAS updates correctly, e.g., when I have SAS on my ship does not turn at all, so maybe that is the problem?)

[Starwaster]

I hate to say this, and I don't know if switching to RT2 would fix things for me . . but I'm just not getting the hang of this Flight Computer, which is making getting a geosynch commsat very problematic. The main problem I'm having that doesn't boil down to just simple errors in keystrokes is that

1. When I queue a delayed burn, it burns. But by the time my ship has orbited around to the position for the burn, the actual position of the blue node vector marker seems to have moved relative to where it was when I set up the burn node.

2. As a result, I keep causing my orbits to get more elliptical and with apoapsis much bigger than my target for my penultimate burn (~2860ish km).

The other thing that is weird, it seems like the ship does NOT orient onto the blue vector marker on its own accord the way it does in JDP's video (perhaps this was a feature added in RT2?). Instead it just burns in whatever direction it is facing.

Add to this that, the exact order in which you: setup a node; turn to align on the blue marker; stop all motion, turn off SAS (having it on when you open the Flight Computer seems to cause the delayed burn to not occur, at least sometimes), open the Flight Computer (I find it must be in this order else the Flight Computer won't work right), type in your burn Dv and delay, hit Maneuver; is rather challenging to execute and any deviation from this order seems to cause the delayed maneuver to fail.

Should I install RT2? Is that likely to fix this stuff?

Is it possible Mechjeb 2.09 is messing things up? (I understand that the stock command pod overwrites from MJ 2.09 are not using the 0.21.1 KSP SAS updates correctly, e.g., when I have SAS on my ship does not turn at all, so maybe that is the problem?)

When SAS is on and in locking mode it all inputs are ignored. Only when it is in damping mode will it allow inputs. That's a KSP thing not a MJ thing. What MJ should be doing is turning SAS off and it seems like it is not. That's probably an MJ thing. What you can do is *NOT* put your craft on SAS manually. Instead, enable Auto SAS in MechJeb. That might not be in the official release though. Get Sarbian's fixes, he's starting his own thread for a temporary MJ2 branch until he hears from the MJ2 dev who seems to be incommunicado at the moment.

Now, the blue marker wandering is a KSP thing, not an MJ thing. It probably has to do with math errors and my personal observation is that it is MORE likely to happen the closer your orbit is to circular. (hey, guess what kinds of orbits we like to make?).

Ok, so looking at the rest of your procedure, I'm not sure why you're running into problems. Flight Computer is a little flaky to use but I do find that it works. Mostly. And I have mine open all the time when I'm setting up my maneuver. It's like this,

I have it open.

I *might* pre-align with something in the general direction of my anticipated node.

I use MJ to set up my maneuver node.

I click Maneuver on the flight computer

Setup DV

Setup Delay

Now, this last.... what delay to use?? The most use I've had out of the Flight Computer is when setting up my relay network. I haven't needed it much otherwise. And my sats are using ion drive. All of them. So I start my delay early. This holds try for any low powered thruster. I set my delay so that it's performing anywhere from 66%-100% of the burn before it ever gets to the maneuver node.

If you're using ion drive, set your delay to start the burn early. That might well make the difference.

Edit: Realized I missed the duration of the burn you're trying to do. Definitely still do an early burn but not to the extent that I suggested. If it's a low powered thruster maybe 40%-50% early

Edited August 9, 2013 by Starwaster

[Diche Bach]

Thanks Starwaster I'll try to make good use of your suggestions.

[CAPFlyer]

Your problem is probably one I have if I'm not careful - MechJeb is still on. Make sure that you DISABLE MechJeb whenever using the RT flight computer to execute maneuvers and you turn off MechJeb Control in the RT control window. This will ensure that when you click "Maneuver" on RT and set the burn and delay, that RT's Flight Computer will have control. Otherwise, MechJeb will lock up the pointing controls as RT is setup to give MechJeb priority over itself.

[Diche Bach]

Yeah, nothing worse than expending 250m/s burning retrograde when you meant to burn prograde.

[crooks4hire]

Been playtesting for a week and a half. The anticipation of RT2's release is already rustling my jimmies...

[Starwaster]

Yeah, nothing worse than expending 250m/s burning retrograde when you meant to burn prograde.

Except realizing that you were sitting there the whole time, mesmerized....

[Diche Bach]

Except realizing that you were sitting there the whole time, mesmerized....

Actually though . . . I'm learning to roll with the punches ala Genesis, Galileo and that Mars one that crashed into the atmosphere . . . This little diametrical burn error has actually proven to be rather useful.

I salvaged that craft into a weird elliptical orbit. When the apo is over KSC it offers excellent comms for a wide angle of the planet! Seems to be helping me to get my first KEO into place. Now if I can just master the art of deciphering the semi-major axis timing thing.

[Ralathon]

Actually though . . . I'm learning to roll with the punches ala Genesis, Galileo and that Mars one that crashed into the atmosphere . . . This little diametrical burn error has actually proven to be rather useful.

I salvaged that craft into a weird elliptical orbit. When the apo is over KSC it offers excellent comms for a wide angle of the planet! Seems to be helping me to get my first KEO into place. Now if I can just master the art of deciphering the semi-major axis timing thing.

Sounds like it is in something approximating a Molniya orbit.

Anyway, semi major axis is really easy to calculate for orbits. Just take the apogee + perigee and divide by 2. Do note that Apogee and Perigee heights are measured in relation to sea level for KSP. So you have to add the radius of the parent body for it to work.

For example, lets say your sat is in a 100 x 500 km kerbin orbit. This means the semi major axis is: ((100+600)+(500+600))/2 = 900km in relation to the center of Kerbin. You can then use this pretty easily to figure out that the orbital period of this satellite is about 47.6 minutes using some simple algebra and readily available info for Kerbins gravitational parameters.

If you want a mod to do all the boring calculations you can always get Kerbal Engineer. The flight capable version of that can tell you the apoapsis, periapsis, semi major, period etc etc while you're flying it. Helps a lot when trying to get evenly spaced constellations out there.

[Starwaster]

Actually though . . . I'm learning to roll with the punches ala Genesis, Galileo and that Mars one that crashed into the atmosphere . . . This little diametrical burn error has actually proven to be rather useful.

I salvaged that craft into a weird elliptical orbit. When the apo is over KSC it offers excellent comms for a wide angle of the planet! Seems to be helping me to get my first KEO into place. Now if I can just master the art of deciphering the semi-major axis timing thing.

I find SMA generally just needs a bit of tweaking as by the time everyone is in their orbit their SMA is only off by a few decimal places. I go into MJ2's Utilities and limit the thrust to 2%. (can't go lower than that because it'll flame out at 1%). I already premade a MJ window that shows me my SMA and my target's SMA so I get that open and target the sat in front of me. Depending on if their SMA is less or greater than mine I do small prograde or retrograde burn. Once I match to their SMA then I switch to the sat behind the one I'm controlling and repeat with them.

USUALLY works well but a few days ago I noticed one of my sats has been drifting so obviously it wasn't QUITE matched up. I still have to get it fixed.

[Diche Bach]

Even if the damn periapsis and apoapsis did not flutter back and forth to opposite sides of the orbit, attaining a perfect geosynchronous orbit by strictly manual control would be a bit of a pain. I have yet to get MJ to work in my favor; so many buttons and settings and I'm just sort of figuring it all out.

Flight Computer I've been doing better with. I still don't get it to turn and orient on its Maneuver vector like it did in JDP's video, but I just manually turn it into place before clicking Maneuver. Apart from the occasional keystroke error it seems to be working okay.

Oh one thing though: it doesn't seem to like running a maneuver node at 1000x speed. I recently had one that I failed to slow down before it executed the maneuver node. The preceding orbit was nearly circular and in the 2650km ballpark, this was to be an apoapsis burn to extend out the periapsis to about 2865 in preparation for the last couple of circularization burns. When it was all said and done I had some weird ~1700 by 4400km ellipse! How that happened simply because of 1000x time warp I cannot fathom.

[Ratzap]

One question I have which the OP doesn't mention: Can the plugin be switched off on the fly while KSP is running?

Meaning can I play in one sandbox with RT switch on, then quit, select a different save and switch it off to play 'normal'?

[Blu_C]

Even if the damn periapsis and apoapsis did not flutter back and forth to opposite sides of the orbit, attaining a perfect geosynchronous orbit by strictly manual control would be a bit of a pain. I have yet to get MJ to work in my favor; so many buttons and settings and I'm just sort of figuring it all out.

Not so much. The key to a Geosync orbit is that the Orbital Period is exactly the same as the rotational period of the planet. For Kerbin that is 6 hours exactly. The orbit doesn't actually have to be perfectly circular for the satellite to remain on station, though if it isn't then it will appear to drift very slightly back and forth with regards to the ground. So to manually get a satellite in a Geosync orbit simply adjust the orbit until the period is exactly 6 hours. This is easy with MechJeb's orbital information readouts (honestly those additional information readouts are the best reason to have MechJeb installed).

[krashkart]

Just a quick question: How do I put three satellites into geostationary orbit around Kerbin all nice and evenly spaced?

Edit: Er... looks like there might be some answers above. Sorry. I just jumped in here in a hurry.

Edited August 11, 2013 by krashkart

[Kimberly]

Just a quick question: How do I put three satellites into geostationary orbit around Kerbin all nice and evenly spaced?

Put all the satellites you're going to release on the same vehicle. Then you have two options: give each satellite propulsion individually, or use only the main vehicle and give it extra fuel.

If you take the first approach, but your vehicle in an orbit with an orbital period that is a fraction of the orbit you want. Your apoapsis should be at geosynchronous altitude. For example, a geosynchronous orbit has an orbital period of 6 hours. If you get into an orbit of 2/3rds that (4 hours), you'll move 1/3rds of a geosynchronous orbit ahead every full orbit you make. Release one satellite at your apoapsis and have it burn prograde until its in a geosynchronous orbit. Wait for the transport vehicle to make a full orbit, then have it release another satellite, and have that satellite burn until it reaches geosynchronous orbit. It should be precisely 1/3rds of an orbit away from the previous satellite. Do the same thing for the last satellite. Use Kerbal Engineer to be able to see your orbital period; you can fine-tune it to a margin of error of about 0.4 seconds.

The second approach is similar to the first. But first you go to into an a geosynchronous altitude and release satellite number #1. Then your transport vehicle goes into the 2/3rds orbit, makes a full orbit, and burns to get back into a geosynchronous orbit, where it releases the second satellite. Repeat for the third satellite. This means you don't have to add any propulsion to the individual satellites, but you'll have to bring more fuel.

[Diche Bach]

Couple questions:

1. What does targeting something actually do?

2. Is it normal that I have two "Open Dish" toggle buttons when I right click items like the stock communotron dish and long antennae? Also when the dish is open, I get two target toggle buttons too.

This is with RT1.

[Sma]

Put all the satellites you're going to release on the same vehicle. Then you have two options: give each satellite propulsion individually, or use only the main vehicle and give it extra fuel.

If you take the first approach, but your vehicle in an orbit with an orbital period that is a fraction of the orbit you want. Your apoapsis should be at geosynchronous altitude. For example, a geosynchronous orbit has an orbital period of 6 hours. If you get into an orbit of 2/3rds that (4 hours), you'll move 1/3rds of a geosynchronous orbit ahead every full orbit you make. Release one satellite at your apoapsis and have it burn prograde until its in a geosynchronous orbit. Wait for the transport vehicle to make a full orbit, then have it release another satellite, and have that satellite burn until it reaches geosynchronous orbit. It should be precisely 1/3rds of an orbit away from the previous satellite. Do the same thing for the last satellite. Use Kerbal Engineer to be able to see your orbital period; you can fine-tune it to a margin of error of about 0.4 seconds.

THis is the one I think I'm going to use. Most of my orbital probes will have ion engines so fuel isn't really an issue, though I haven't thought about the power issue, if one of them is stuck on the dark side for a good part of the orbit. I'll have to double check that. I guess I could throw on a few RTG's, that should keep the sensors/radios powered I would hope. So long as it has enough power to run the ion engine to get into geosync. Of course for the "geosync" polar ones, they shouldn't be in the dark as long. I guess I'll worry about this once RT 2 becomes available.

[DoubleOSeven1]

THis is the one I think I'm going to use. Most of my orbital probes will have ion engines so fuel isn't really an issue, though I haven't thought about the power issue, if one of them is stuck on the dark side for a good part of the orbit. I'll have to double check that. I guess I could throw on a few RTG's, that should keep the sensors/radios powered I would hope. So long as it has enough power to run the ion engine to get into geosync. Of course for the "geosync" polar ones, they shouldn't be in the dark as long. I guess I'll worry about this once RT 2 becomes available.

The Poles rotate, there can never be a such thing as a geosync Polar Orbit