-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Noise background to affect communications link range #706
Comments
Good point there. I never thought about the noise that gets caught on the recieving end when pointed at a body instead if the deep space. I would like to see this in RT eventually but it will take quite a lot of research to get things right. |
Thank you for the kind reply. |
Not to diminish the realism--and do please correct me if my understanding lacks--but given the fact that RemoteTech doesn't pay attention to frequency, would it be possible to simulate something like this idea of 'average noise' more simply by using a formula that calls, or is related to, the existing body occlusion multiplier? Stock KSP already allows one to set the multiplier to values larger than a body's radius, so the machinery exists to detect and affect vessels in space near such a body. If RemoteTech were, for example, to use that multiplier to define a sphere centred on a body and systemically degrade a signal as it passes near the centre of that sphere (such degradation being offset by higher-power antennas, of course), would that be what you're asking? This has the advantage of using existing stock path algorithms to select a signal relay with less degradation, if one is available, to send a signal that otherwise passes near (but not through) a large body on its way to another target (the obvious use case is trying to talk to Duna while trying to dodge the Mun and Ike). Additionally, I suppose there would need to be something special put in place for signals that pass near the sun. I haven't launched any low-orbit solar experiments in stock, and I definitely haven't tried to communicate between a vessel and Kerbin when they are on opposite sides of the sun from one another, either, so I do not know how (or whether) stock addresses this except to say that the sun does have a defined 'atmosphere', so it perhaps is affected by the atmospheric body multiplier. If so, I think that that would have to change in order to implement this idea. On the other hand, I think the sun ought to degrade any signals that pass near it anyway--to do otherwise threatens my suspension of disbelief. I am minded of an episode of the Outer Planets Travelling Circus (Mission Reports) where a signal passed close to the sun and, for story reasons, the author had to pretend that this made it unintelligible. The issue was that RemoteTech chose its path based on shortest delay, not strongest signal, and that could still be an issue in pursuing this idea. On the third hand, RemoteTech is going to need to resolve this anyway because stock antennas choose paths by signal strength and don't simulate delay. If RemoteTech 2.0 is going to include both, then it will need to be able to choose between strong signal and short delay, I assume based on some user input--possibly even via an in-flight tweakable for special cases--so that would make it a moot point. |
@Zhetaan If I understand diomedea right he's talking about celestial bodies behind a transmitter (as observed from the reciever) raising the background noise level. For this to be an issue, this body needs to cover significant (not necessarily large) portion of reciever's main lobe's solid angle. Large bodies like Kerbol or Jool may cause signal degradation for vessels that are still very far from them (I guess). This cannot be simulated by the atmospheric interference. |
Ah, right. In other words, we're looking for a solution that covers such cases as, for example, receiving at Kerbin from the Mun while the Mun is eclipsing the sun; the signal from the Mun will be there, but a lot of solar noise should be there, as well. It strikes me that such a thing must be doable; as for whether it is practicable, well, I leave that to your capable coding skills. For my part, I think it's a great idea that would provide further justification for backup relay networks even in near-Kerbin space (I like things that remind me--especially in early career--that yes, there is a whole solar system out there). I think that, done well, it could also provide a much more fulfilling experience for something such as the Outer Planets Mod given that all of the giants exhibit at least some radio activity in reality, though obviously it's rather premature to be discussing potential mod integration for a feature on a wishlist that may or may not be implemented in an as-yet unreleased version of RemoteTech. Anyway, I think I've taken enough of your attention away from RemoteTech 2.0 development, so I will leave you to say that, even though I had the wrong idea of what this was about, I am still very much in favour of the team taking a serious look at implementing this in the future. |
Glad to find such interesting comments. I didn't even consider this feature could provide reason for relay networks close to Kerbin, but certainly should give players a more realistic experience with managing a communication network. The power of noise received can be (rather easily) computed known the whole power emitted from the interfering body, the selectivity of the receiver, and either the solid angle the receiving antenna has at the distance from that body or the antenna gain and distance. With the representation of directive antennae lobes as currently in RT, gain Gr is always the same within the lobe, always = 0 outside the lobe. Using antennae to establish a link with only one transmitter (that will always be seen on the main axis of the lobe), the above representation is perfectly working. However when considering emitters at an angle from the axis, the effective law about gain needs be considered. What are conventionally considered the main lobe "borders" are actually the directions where gain is halved (3 dB less than maximum, as in https://en.wikipedia.org/wiki/Main_lobe). But, power is received with an even lesser gain from any direction farther away from the axis. Without dealing with side lobes (those would make computing gain almost impossible), a good enough representation of variable gain is by the distance of a point on an ellipsoid in the specific direction where the body lies IRT to antenna. Believe a picture helps: http://imgur.com/4Z3QIgc. We have a Rx antenna pointing at a Tx vessel. The maximum gain of the Rx antenna is along the axis (distance from Rx to the ellipsoid in the axis direction). The two blue lines are the conventional limits at -3 dB (half distance, half gain; that happens to fall on the semi-minor axis of the ellipsoid). We also have Sun, apparently outside the lobe, but effectively it still is received with a gain proportional to the distance from Rx to the ellipsoid in the Sun direction. The antenna depicted in the pic isn't very directive, so gain in the Sun direction is still too high: a properly directional antenna would have only a fraction of the gain from the sides of this one. The picture is actually best for showing the variable gain problem; but I'm sure simpler equations (than solving distance from an ellipsoid) can be used to implement that. Now, when the emitting body can be considered a dot (its solid angle seen from the receiving antenna extremely small), the above would be all. And actually only the above was in my suggestion. But as remarked in previous comments, if a body is near enough its solid angle needs be computed too. |
@diomedea Thanks for all the information gathered in one place. |
Range in communications is customarily computed using the Friis equation, and RT does quite in a good way too, at least when adopting the root model. Sure enough, polarization (with both transmitting and receiving antennae) isn't included, and reflection is "cumulated" with gain. But those simplifications don't really affect realism much.
One major factor isn't however factored in, and it much more affects realism. With the Friis equation, we compute the Pr (received power) at the receiving antenna. There is no consideration about the noise power that same receiving antenna is catching. A receiver can generally make apart signal from noise, up to a limit when the signal to noise ratio (S/N) remains greater than 1. That means, in real communications, received noise needs be reduced with all possible means (limited receiver bandwidth, very high frequency selectivity, very high antenna gain). Deep space communications need to use such techniques to the extreme (e.g., internal receiver noise is contained by low circuitry temperature). One factor however remains: the effective average noise power from the specific direction the receiving antenna is facing. When pointing towards an object in deep space, received noise is as low as the cosmic background noise. Having the antenna aiming a near body, brings the thermal radiation from that body as additional noise (at the specific frequency the receiver is tuned to). Of course, inhabited bodies like Earth add a whole world of background noise from human presence. But the real problem is when Sun enters the equation: its thermal noise is many times higher than signal from a distant vessel. The aiming direction and directivity of the receiving antenna are crucial to keep received noise low, so a choice with a very high gain antenna and very high frequency (that helps with reducing both size of the antenna, and the relative percentage of received noise from the whole radiation spectrum according to Wien).
Sorry for the length of the explanation above, back to RT. It would be great to have the average background noise in the direction aimed by the receiving antenna modelled. Therefore, when e.g. Sun is close in angles to the direction of the transmitter (seen from the receiving antenna), its thermal noise enters the equation causing a reduction in range. Main factors are frequency used, distance from Sun, and angular difference against antenna gain.
Of course computing noise level would have some weight on performance, and some players would prefer not to deal with it. Playability against realism, as often there's a choice to be made. I'd leave players the ability to choose with a RT setting, if they want one or the other.
The text was updated successfully, but these errors were encountered: