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

[diomedea]

If I was going to model this, I'd be even meaner about it. Won't the interference cause problems if the vector of the communication points at the sun, even if the sun is behind the target? This would mean that you're more likely to want geosync satellites, as you can position two of them so that they're always visible from KSC, so if the sun is behind one of them, you can relay through the other. Using lower altitude constellations would mean accepting a communications blackout whenever there's only one satellite visible from KSC and the sun is right behind it, which would probably happen quite often.

As I understand it, the most accurate way to represent this would be to reduce the range of any communications that would be coming from a vector with a retrograde that points at or near the sun, with the effect becoming less pronounced as the retrograde vector moves away from the sun, simulating the fact that the transmitting antenna's signal is getting lost in the background noise. If it's closer, it could still overpower the background noise. Which isn't to say that we need that accurate of a model for this to be an interesting mechanic.

Edit: On second thought, this might not cause problems with lower altitude constellations, since those are usually based on omnidirectional antennas, which are already dealing with the solar interference.

Your proposal is quite accurate, as it correctly considers some of the factors that involve noise in communications.

However, please let me also show what I consider a plausible system.

The amount of background noise, in reality, can be computed just with the same equation that gives the received signal power (Friis equation). In a different form, that equation provides the actual range of a communication system. Please note RemoteTech currently computes range in a very different way, still some viable mechanic can be introduced to simulate background noise accounting for the following:

- the beamwidth of the receiving antenna (or, its gain, as the two are closely tied);

- the angular difference between the transmitter and the noise source, as seen by the receiving antenna;

- the relative distances of the transmitter-receiver link and noisesource-receiver link, to the power of 2;

- the relative power of the trasmitter and the noisesource (currently unknown), multiplied by the respective gain;

- the bandwidth, or selectivity, of the receiver (currently not defined in RemoteTech2).

The last two factors are not factored in RemoteTech2 currently, so an acceptable value has to be chosen that makes for an acceptable mechanic in game, without introducing further difficulties to players.

Many other factors would be considered in reality (carrier frequency, polarization, losses, antenna impedance...) but would only overcomplicate things, so am leaving them out.

Knowing the relative amount of signal and noise power provides the S/N ratio, which is one of the most important factors to determine range in reality.

But also, S/N ratio is very important to determine the datarate, or the channel capacity of the communication link (Shannon-Hartley theorem). A low S/N ratio limits the channel capacity, and that should bear to a smaller PacketSize (or longer PacketInterval) with the antenna (possibly to be simulated by coding a variable speed of transmission in RT2).

Hope the above is of interest; I already have parts of the math behind real communication systems covered, so could help in case developers wanted to consider it.

[mecki]

I have a question that may sound stupid but I couldn't find a definitive answer in the tutorial:

Is it sufficient for a relay satellite to have just one omnidirectional antenna or do I need to have one per connection (one to connect to KSC, the other one to connect to probe / ship / other COMSat…

[veryinky]

Is it sufficient for a relay satellite to have just one omnidirectional antenna

Only need one omni antenna per satellite, connects to everything within range. Dishes are directional so you need one per connection.

[mecki]

Only need one omni antenna per satellite, connects to everything within range. Dishes are directional so you need one per connection.

Thank you very much for this quick clarification!

If I point a dish to "active vessel" would it also connect with another vessel (e.g. the "mothership") if it was slo within the cone? Or does this only work if I point it to the corresponding planet?

[TaxiService]

Thank you very much for this quick clarification!

If I point a dish to "active vessel" would it also connect with another vessel (e.g. the "mothership") if it was slo within the cone? Or does this only work if I point it to the corresponding planet?

Based on what I played, yes, a vessel with directional dish will connect to all vessels included active one within its cone. The dish can connect to omni antenna within too. I point one dish with widest cone at Kerbin, and the omni-only satellites orbiting the planet will connect to the dish (if they have the disk within their ranges). Correct me if I am wrong.

Edited July 31, 2014 by TaxiService
More details

[mecki]

If I build a satellite with an additional reaction wheel, the flight computer makes my craft wobble and doesn't stop. it points into the right direction but doesn't stop to wobble. In this situation I can neither time warp nor change focus.

If I disable the reaction wheel, the flight computer overreacts and is not able to point into the right direction, the satellite keeps tumbling.

If I disable the torque of the probe core, the flight computer is able to point into the right direction but the ship keeps wobbling.

MechJeb works with all of these configurations flawlessly.

Is this a known problem? Are there workarounds (e.g. placement ob probe core and reaction wheels)?

And what should also be in the manual: Dishes are best to be symmetrical since even one Comms DTS-M1 placed on the side is sufficient to make a small probe tumble while the Flight Computer is executing a burn.

[TaxiService]

If I build a satellite with an additional reaction wheel, the flight computer makes my craft wobble and doesn't stop. it points into the right direction but doesn't stop to wobble. In this situation I can neither time warp nor change focus.

If I disable the reaction wheel, the flight computer overreacts and is not able to point into the right direction, the satellite keeps tumbling.

If I disable the torque of the probe core, the flight computer is able to point into the right direction but the ship keeps wobbling.

MechJeb works with all of these configurations flawlessly.

Is this a known problem? Are there workarounds (e.g. placement ob probe core and reaction wheels)?

And what should also be in the manual: Dishes are best to be symmetrical since even one Comms DTS-M1 placed on the side is sufficient to make a small probe tumble while the Flight Computer is executing a burn.

Did you command your craft to react to a maneuver node? I tested a simple 0.6-ton craft with a reaction wheel and set up a maneuver node ahead of its path. When I command it to hold maneuver prograde (node button). It indeed wobbles around the blue point on the nav-ball with and without torque, but I am able to time-wrap, cancelling the wobbling. I think the problem is the torque is possible too overwhelming for your little-mass craft to handle. Larger-mass crafts would be able to overcome the torque sweep.

Can you check this?

Edited July 31, 2014 by TaxiService
Clarify

[CaptainKipard]

Would that be an invisible sphere that blocks the line of sight for comm links, or an "Anything below an altitude of 10xradius cannot connect to the network"?

Ok the discussion got derailed a little. I meant an invisible sphere, like this:

[mecki]

Did you command your craft to react to a maneuver node? I tested a simple 0.6-ton craft with a reaction wheel and set up a maneuver node ahead of its path. When I command it to hold maneuver prograde (node button). It indeed wobbles around the blue point on the nav-ball with and without torque, but I am able to time-wrap, cancelling the wobbling. I think the problem is the torque is possible too overwhelming for your little-mass craft to handle. Larger-mass crafts would be able to overcome the torque sweep.

Can you check this?

Yes I did.

My vessel has 1.5t and I wasn't able to start time-warp (due to acceleration). My probe core is at the top of the probe whereas the reaction wheel is further down.

But as I said: When I disable the torque of the reaction wheel, the Flight Computer is not able to get the direction right at all. It keeps oversteering and won't stop to tumble.

[undercoveryankee]

Thank you very much for this quick clarification!

If I point a dish to "active vessel" would it also connect with another vessel (e.g. the "mothership") if it was slo within the cone? Or does this only work if I point it to the corresponding planet?

The cone exists only if the dish is targeted to a body (planet or moon). Targeting "active vessel" means only one vessel at a time. But if the dish is targeting a planet it will cover any vessel in the cone in that planet's SoI with range and line of sight.

[mecki]

The cone exists only if the dish is targeted to a body (planet or moon). Targeting "active vessel" means only one vessel at a time. But if the dish is targeting a planet it will cover any vessel in the cone in that planet's SoI with range and line of sight.

Thank you!

And something else: How do mods like FAR and Procedural Fairings (or fairings in general) interact with the connectivity of antennas and there vulnerability to high speeds in atmospheres?

[elfindreams]

Thank you!

And something else: How do mods like FAR and Procedural Fairings (or fairings in general) interact with the connectivity of antennas and there vulnerability to high speeds in atmospheres?

Currently fairings do nothing for or against connectivity and vulnerability. You can connect through a fairing fine, but if you try to go fast in an atmosphere with a fragile antenna under a fairing it will still blow off.

[mecki]

Currently fairings do nothing for or against connectivity and vulnerability. You can connect through a fairing fine, but if you try to go fast in an atmosphere with a fragile antenna under a fairing it will still blow off.

Thanks for pointing this out!

Is this something that is on the to-do list?

[PUNiSH3R]

Thanks for pointing this out!

Is this something that is on the to-do list?

I think that was the point of the Reflectron DP-10; just enough range to get you exoatmospheric, then forces a 'staged' deployment of longer range communication.

[mecki]

Currently fairings do nothing for or against connectivity and vulnerability. You can connect through a fairing fine, but if you try to go fast in an atmosphere with a fragile antenna under a fairing it will still blow off.

And ist this also true with FAR installed?

[mecki]

I think that was the point of the Reflectron DP-10; just enough range to get you exoatmospheric, then forces a 'staged' deployment of longer range communication.

With FAR installed you would use fairings anyway. Those MIGHT disturb connectivity and MIGHT allow early unfolding…

[OminousPenguin]

And ist this also true with FAR installed?

Yes. If I remember correctly, currently the RT2 code ignores whether the antenna is shielded or not.

[PUNiSH3R]

And ist this also true with FAR installed?

I can verify it is; deploying a Comm. 16 omni inside of a fairing while in atmosphere will snap it under FAR high dyn pressure. I made that mistake early on (more than once...)

With FAR installed you would use fairings anyway. Those MIGHT disturb connectivity and MIGHT allow early unfolding…

I mount the DP-10 externally (i.e., unshielded) on the trans-atmospheric stage; once you're over 70km or so, deploy your primary comm via an action group when you decouple your fairing and kick loose the TA stage at will.

[elfindreams]

And ist this also true with FAR installed?

It is true with NEAR and FAR.

With FAR installed you would use fairings anyway. Those MIGHT disturb connectivity and MIGHT allow early unfolding…

They do not. (They still behave like they are in open air).

NOTE: one useful thing to do (If you find yourself forgetting to deploy or like I do taking a way too horizontal orbital approach and sometimes just missing the window) is to use these:

http://forum.kerbalspaceprogram.com/threads/64227-0-24-1-27-July-Smart-Parts-V2-0-New-API-and-new-KM-folder-structure

What I do is place a smart altimiter part with a action group set to jettison the fairings and deploy my omni-directional. If I forget to deploy as long as my suborbital takes me above the programmed height, I regain control and can continue my ascent. I set it for 50k ascent.

Edited July 31, 2014 by elfindreams

[Fluitj]

I have this most weird thing: my signals take no notion of Kerbin being where it is. In other words: my comsignals are going through the planet. Is anyone else having the same issue?

[undercoveryankee]

NOTE: one useful thing to do (If you find yourself forgetting to deploy or like I do taking a way too horizontal orbital approach and sometimes just missing the window) is to use these:

http://forum.kerbalspaceprogram.com/threads/64227-0-24-1-27-July-Smart-Parts-V2-0-New-API-and-new-KM-folder-structure

What I do is place a smart altimiter part with a action group set to jettison the fairings and deploy my omni-directional. If I forget to deploy as long as my suborbital takes me above the programmed height, I regain control and can continue my ascent. I set it for 50k ascent.

With the proliferation of "test part flying at Kerbin" contracts that require interesting combinations of speed and altitude, I decided that I wanted to guarantee that a DP-10 would never lose signal. So my first ring of communication satellites became eight Communotron 16s orbiting 175km above the equator. With that spacing, a DP-10 will connect from surface to at least 350 km anywhere along the equator. Maybe overkill, but it saves hassle and power requirements on everything else in LKO.

[sidfu]

under u could get away with having 4 geo sats. what i normaly do is put 4 geo up at equator aen put 2 go distance but going polar in oposite directions pretty much gives me coverage and a back up without to many sats. after that i put 1 equator one way out at edge of kerbin orbit and one going polar normaly covers all i need. lat i just put 2 sats around mun and minmus and pretty much dont have much problem with kerbal system long as u point your dishes right and use right ones

[elfindreams]

With the proliferation of "test part flying at Kerbin" contracts that require interesting combinations of speed and altitude, I decided that I wanted to guarantee that a DP-10 would never lose signal. So my first ring of communication satellites became eight Communotron 16s orbiting 175km above the equator. With that spacing, a DP-10 will connect from surface to at least 350 km anywhere along the equator. Maybe overkill, but it saves hassle and power requirements on everything else in LKO.

LOL better than my original solution, I had a ring of 11 ground based repeaters along the equator That was a pain to put into place, and I lost many of them to a tweakscale kraken issue.

[mecki]

under u could get away with having 4 geo sats. what i normaly do is put 4 geo up at equator aen put 2 go distance but going polar in oposite directions pretty much gives me coverage and a back up without to many sats. after that i put 1 equator one way out at edge of kerbin orbit and one going polar normaly covers all i need. lat i just put 2 sats around mun and minmus and pretty much dont have much problem with kerbal system long as u point your dishes right and use right ones

Do you get all-time polar coverage with the two opposing satellites? No, right? Or am I missing something? I'm just trying to understand it.

[sreinmann]

Did i miss it, or has no one come up with a suitable patch to address the signal degradation in transmitting science? Have we confirmed that this is limited to 64bit platforms or both?