Jump to content

Now-defunct-thread-that-should-not-appear-in-google-search.


Cilph

Recommended Posts

Ok, now I'm confused by how this mod behaves... (again).

I have an array of satellites each equipped with four KR-14 dishes, one of which (on each satellite) is targeted at "Active Vessel". The array is in constant contact with Mission Control, and each bird has sufficient power. I send a probe equipped with two KR-14's and fully powered on a Kerbin escape trajectory.... and I lose contact just past the Mun's orbit at a miniscule fraction of the KR-14's rated range. (Even with one of the two KR-14's set to target Kerbin.) Send a similar probe out past Minmus yields the same result and an interesting observation - it regains communication just before it crosses the Mun's orbit inbound. WTF is going on here?

You have 4 sats pointing to your ship, and the ship pointing to Kerbin, with dishes of very narrow coverage. With two dishes onboard of the ship, it would be safer to point to two of the Kerbin satellites individually, two that are about 180º appart from each other, to have one of them permanently in sight. Pointing to Kerbin points yout ship dish to the center of Kerbin planet, while your satellites are Km away from there, and a slight orbit inclination may make them not go though your dish cone. That said, once your ship goes far enough the dish coverage cone as narrow as it is, gets to be big enough to see the satellites around Kerbin and you get connection. I use the active vessel/Kerbin as you and usually I get connection about one quarter orbit away from Kerbin, when in trajectory to Eve or Duna.

Link to comment
Share on other sites

So, with this latest update, I noticed that out of contact sats can still deploy their antennas. Is that a planned function, because I'm fairly sure you couldn't before. I was launching a sat and forgot to deploy the long range antenna, and in a frustrated panic, spammed the deploy hot key, and watched in amazement as the antenna deployed and the rocket engine reignited. TOSLS II made its orbit. I may have just installed something wrong for it to work like that, but I thought I'd check.

Link to comment
Share on other sites

Chatterer should already have RT1 integration. I'll see if I can hook it into RT2 using the same system.

EDIT: Nope. Chatterer needs an update.

I use chatterer, and it seems to work fine with rt2. Or are you talking about a specific function?

Link to comment
Share on other sites

So, with this latest update, I noticed that out of contact sats can still deploy their antennas. Is that a planned function, because I'm fairly sure you couldn't before. I was launching a sat and forgot to deploy the long range antenna, and in a frustrated panic, spammed the deploy hot key, and watched in amazement as the antenna deployed and the rocket engine reignited. TOSLS II made its orbit. I may have just installed something wrong for it to work like that, but I thought I'd check.

Huh. Yesterday I could run a Goo experiment on my out of range probe, but could not send the data. Thought nothing of it, but now ... ?

Link to comment
Share on other sites

I don't know if it's my mis-look or not... but it seems like the flight computer's delay functionality has some problem *sometimes*.

And... yes i'm aware that out-of-electric-charge may (or may not) pause the timer. No, in my case I'm not lacking of power at any moment.

I enqueued a task which should start about 12 minutes later, but found out that after the time warp, when i got close to the maneuver node, the timer was still having several hundreds seconds left there... and the burn was totally happening at a wrong place/time.

And this issue doesn't always happen, i just wonder what's wrong with my operation or with the plugin...

Link to comment
Share on other sites

Cilph:

Signal Delay

Signal Delay is not currently activated in this lite version. In the future when proper automation will be included (Flight Computer and/or kOS integration) controls will have an execution delay dependent on the distance and the speed of light. Managing your signal delay as well as pre-planning your actions becomes more important the further out you go. Signal Delay can be up to 15 minutes near Jool(!)

Would you be so kind as to change the forum header post to reflect that you have enabled time delay/or can you disable this as the default setting?

Also could you include a link to the post where the KOS mod can be found. It is unclear that the mod isn't included by default/isn't part of the mod.

I happen to be one of those ppl that actually reads the change-logs but for anyone who doesn't and only reads the header post this can be very unclear.

Link to comment
Share on other sites

I'm having a bit of a problem. For some reason parts of this mod do not show up in the career mode. Have I missed something?

Did you purchase them in the R&D building? If you added the mod after you unlocked the tech, you need to purchase the part.

Cilph:

Would you be so kind as to change the forum header post to reflect that you have enabled time delay/or can you disable this as the default setting?

Also could you include a link to the post where the KOS mod can be found. It is unclear that the mod isn't included by default/isn't part of the mod.

I happen to be one of those ppl that actually reads the change-logs but for anyone who doesn't and only reads the header post this can be very unclear.

Will do.

---

Anyhow on the topic of MechJeb. I've determined the throttle jitter to be completely related to MechJeb. It has several internal control loops that interfere with signal delay. The jitter while the part is OFF however, has been found to be caused by a piece of old code in MechJeb that no longer is required.

I will forward the issue to r4m0n and in the meanwhile I will remove the ModuleSPU on the mechjeb part so that signal delay no longer applies and causes issues. Simply remove the RemoteTech_MechJeb.cfg file or disable signal delay while this issue persists.

Edited by Cilph
Link to comment
Share on other sites

I wonder if this old code in MJ would make MJ run much better, if taken out. I'll wait to see and run MJ by itself. That is a really good find.

Like I said, having MJ installed on a clean KSP install and no other mods. MJ kills like 10 or fps, even when not turned on, just by having part on rocket.

Link to comment
Share on other sites

One little issue that I've run into today but haven't been able to 100% confirm as a bug - relay logic in the current public release is not 100% working.

I have setup my TDRSS system per my standard format (A, B, and C). Each TDRSS satellite has 4 dishes. The A has a dish pointed at KSC, B and C have one pointed at A currently after I ran into a problem where I would not get a connection when C was pointed at B. In the Tracking Station view, only A - KSC shows a link active. C - A - KSC, and B - A - KSC only show active when I highlight the respective satellites. This behavior is changed from previous versions where all active connections always show.

The other 3 dishes on all 3 satellites are pointed at the Mun, Minmus, and Active Vessel.

Then I launched a 2-stage Mun probe. There was the lander part and the orbiter part. The lander only has a Communitron 16, but the Orbiter has a Communitron and a dish. One in Munar orbit, everything works okay, but after decoupling, I twice lost contact when under 5km during the landing phase even though the map showed a link line to the Orbiter (which was not green showing active link to KSC). I'm wondering if there's something going on with the link logic not working correctly and finding the link active even though it's finding a pathway. I pulled my output.log file and found no exceptions being generated, so I don't think it's anything malfunctioning.

Link to comment
Share on other sites

Might forward to sarbian too, he has been working on the devbuilds lately.

Did you purchase them in the R&D building? If you added the mod after you unlocked the tech, you need to purchase the part.

Will do.

---

Anyhow on the topic of MechJeb. I've determined the throttle jitter to be completely related to MechJeb. It has several internal control loops that interfere with signal delay. The jitter while the part is OFF however, has been found to be caused by a piece of old code in MechJeb that no longer is required.

I will forward the issue to r4m0n and in the meanwhile I will remove the ModuleSPU on the mechjeb part so that signal delay no longer applies and causes issues. Simply remove the RemoteTech_MechJeb.cfg file or disable signal delay while this issue persists.

Link to comment
Share on other sites

I could answer this by trial and error in my own game but I'm lazy and I figure someone will know off the top of their head. Is the maximum range of a connection determined only by the range of the shorter antenna? I know that in version 1, pointing a dish at an omni could increase its range by 1.5x (I think); is this no longer the case?

Link to comment
Share on other sites

I could answer this by trial and error in my own game but I'm lazy and I figure someone will know off the top of their head. Is the maximum range of a connection determined only by the range of the shorter antenna? I know that in version 1, pointing a dish at an omni could increase its range by 1.5x (I think); is this no longer the case?

No longer the case.

Link to comment
Share on other sites

A couple of questions.

If I understand correctly, to get a good KSO orbit for a satellite you need a semi-major axis of ~3469km and a period of 6 hours flat. I guess that small variations in the distances of periapsis and apoapsis are not that important if you can see mission control at all times.

Now, how close do you have to be to the orbit period for a good grid? I'm asking since using RCS for orbit corrections jump my numbers 5s per push or so and getting exactly 6hrs is very difficult with my current design. If you are one or two seconds off, how much is it going to bother you in a couple of years of game time?

And a second question. I see that dishes have a cone variant. Does that mean that the dish has to orient itself with the target so that it works? When you choose a target is it done automatically, or do you have to point the sat to the correct location?

Link to comment
Share on other sites

If I understand correctly, to get a good KSO orbit for a satellite you need a semi-major axis of ~3469km and a period of 6 hours flat. I guess that small variations in the distances of periapsis and apoapsis are not that important if you can see mission control at all times.

Now, how close do you have to be to the orbit period for a good grid? I'm asking since using RCS for orbit corrections jump my numbers 5s per push or so and getting exactly 6hrs is very difficult with my current design. If you are one or two seconds off, how much is it going to bother you in a couple of years of game time?

Just have them all at the same speed - use capslock to enable fine control, press with different pressure on the key to fine tune in.

Should be enough to have three sats at 800+ km.

And a second question. I see that dishes have a cone variant. Does that mean that the dish has to orient itself with the target so that it works? When you choose a target is it done automatically, or do you have to point the sat to the correct location?

It is automatically targeted, no visual/3D representation is seen.

But the cone only works when targeting planets/moons, targeting a dish at a vessel establishes a link, but only to this one vessel.

I will forward the issue to r4m0n and in the meanwhile I will remove the ModuleSPU on the mechjeb part so that signal delay no longer applies and causes issues. Simply remove the RemoteTech_MechJeb.cfg file or disable signal delay while this issue persists.

Making the MechJeb an AI ship computer. :D

Link to comment
Share on other sites

Now, how close do you have to be to the orbit period for a good grid? I'm asking since using RCS for orbit corrections jump my numbers 5s per push or so and getting exactly 6hrs is very difficult with my current design. If you are one or two seconds off, how much is it going to bother you in a couple of years of game time?

Depends on the height. If you're a second off on your kerbostationary you'll be 10% off after 540 days, if I didn't muck up my math too badly.(looking at the numbers I probably did) however being 1s off on a ~420km orbit (~57½ minute orbit) will be noticeable in under two weeks as I've discovered.

Do you have fine control enabled for your RCS adjustments? Anyway, instead of RCS, use the flight computer and burn with your main engine. Doing 0.68% thrust for 0.01s burn time makes for some tiny adjustments in orbit. :) That burn addition to SASS is absolute grade-A 100% pure awesomesauce for matching orbital period/semimajor axis of satellite constellations. :cool:

Okay, that spectacular crash with 1.2.0 isn't happening, I can't make it misbehave too badly so I shall update. Flight computer delays seemed to be a bit buggy when out of contact, but I might have just been out of power as well as out of contact so can't confirm. One issue I found was that a satellite around kerbin with a dish pointed at minmus, and a satellite in orbit of minmus with a dish pointed at kerbin, can't communicate to each other. If one of them then changes their target from the Celestial Body to the Satellite, it works just fine.

[edit] Nevermind, I was being stupid, the satellite I was trying to catch wasn't actually at minmus, it was in Kerbin SOI right next to minmus at the same orbit, which is why aiming at Mun didn't link it despite it being in the cone. Next bit is still valid though:

Also a dish at minmus pointed at kerbin, with a cone wider than the orbit of the Mun, doesn't catch objects inside Muns SOI despite them being in LOS and range of the dish, though this might be an engine limitation?

If those have been fixed after 1.2.0 or are WaI, nevermind. Else, I'll get some shots and a log next time I'm playing :)

Edited by Sacred Aardvark
editing instead of double posting is good practice.
Link to comment
Share on other sites

Hehe, I don't have a main engine, only RCS on the sats.

By using fine control I managed to have a difference of 0.1'' between them. So according to your math it should be about 1% difference in 540 days.

For the next batch, I'm going to grab the tiny RCS blocks (0.15 thrust) from AEIS. That should do it!

It is automatically targeted, no visual/3D representation is seen.

But the cone only works when targeting planets/moons, targeting a dish at a vessel establishes a link, but only to this one vessel.

Hm, I don't understand the difference. If the dish is set to target the active vessel, each time you change to another one it will automatically target it if its in range, right? So why target a planet/moon?

Link to comment
Share on other sites

Hm, I don't understand the difference. If the dish is set to target the active vessel, each time you change to another one it will automatically target it if its in range, right? So why target a planet/moon?

Only when targeting a planet/moon will the dish try to connect to ANY antenna/dish in range inside the cone. Handy to target all Kerbin satellites from a Munar satellite with the small dish (25 degree cone).

Link to comment
Share on other sites

Ah got it, thanks...for example I can use the dish in a KSO satellite to target a mun satellite that targets the active ship that is behind the mun and obscured from the KSO satellite.

Correct, but because all satellites rotate, simplest way is to:

Let orbits around bodies be low enough in orbit to be in range of each others omnidirectional antennes, have their dishes target Mun/Kerbin(Minmus) to bridge that gap by establishing links whenever available, have long range dishes target active vessel.

Link to comment
Share on other sites

A couple of questions.

If I understand correctly, to get a good KSO orbit for a satellite you need a semi-major axis of ~3469km and a period of 6 hours flat. I guess that small variations in the distances of periapsis and apoapsis are not that important if you can see mission control at all times.

Variations in peri/apo mean very little. Viewed from the ground, the target will drift back and forth and return home each day. With some inclination it'll drift in an ellipse. You'd need quite large variations (hundreds of kilometers) to lose contact with the ground.

Now, how close do you have to be to the orbit period for a good grid? I'm asking since using RCS for orbit corrections jump my numbers 5s per push or so and getting exactly 6hrs is very difficult with my current design. If you are one or two seconds off, how much is it going to bother you in a couple of years of game time?

1 second per 6 hours is .004%. So you'll drift about 7 degrees per year (if I have that math right). After about 12 years you may no longer be in contact with KSC if the satellite was stationed directly above it. A bit worse, it depends on your error. If you have two adjoining satellites and they're each off by a second in different directions, then you may lose coverage even faster - or wind up with both satellites in shadow for extended periods. So at the very least, get all of your error either fast or slow. If they're all off by a second in the same direction, then your array will remain intact but slowly rotate around the planet, which is much more acceptable.

There are some low-power RCS ports in some of the mods. AIES has a small 1/6th power one. A single linear RCS pusher is also handy for this, though you'll need to rotate the craft for direction. You can also use an ion drive for this, which is quite low power. If you use MJ, it has a handy feature under the 'Utilities' panel to limit throttle. Limit it to 1% and you can get thrust down to .005 which is much lower than you can usually get with RCS. You can get a little lower with a mod ion engine. Roemi-Lemdum Atomics has a .25 thrust mini ion engine which is handy for this. I can usually get my orbits within .1s. Kerbal Engineer Redux will give you orbital periods to .1s.

And a second question. I see that dishes have a cone variant. Does that mean that the dish has to orient itself with the target so that it works? When you choose a target is it done automatically, or do you have to point the sat to the correct location?

The dish doesn't need to orient, but it does need to be given a target. It does this automatically, and if the antenna is physically pointed away from the target, it still works fine. The cone only really matters (from what I can see) when you point it at a body, rather than a spacecraft. If you are around Duna and select Kerbin as your target, the narrowest cone dishes won't be wide enough to paint your geosync array. In fact, it might fire right between two of your sats and if KCS is on the other side of the planet, you'll lose connection. So there's a tradeoff between distance and cone angle. A long range, narrow dish used at short range will target individual satellites fine (until they orbit behind the planet), but will probably miss most or all of your array if you point it at the planet unless you have a low altitude array.

Within the Kerbin system, you want a nice wide angle because your geosync array will be dozens of degrees wide from Mun, and maybe 10deg from Minmus. Personally, I think the angles set by RT2 are a bit too narrow for the long range dishes. I can't imagine designing a dish for Jool that couldn't cover the angle of a geosync network (no need for more, though) and the current settings are just a bit shy for that. They'll definitely fire through a 4 sat network from Dres.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...