Yamori Yuki

It's hard to say but as it is now we may or may not make it in Q2.

@NemesisBosseret First of all, please let me apologise for my snarky remark at the end of the post, it was rather impolite. About frequency labeling: Unfortunately when one's reading about civilian space radio communication the IEEE radar frequency band standard is still used anywhere exact frequencies are not important, so I keep using them for consistency with those sources. Sorry if it's confusing. About Apollo: Here's citation from the source you linked, right from the third paragraph: Yes, the unified S-band system was certainly not the only one used, but it definitely was the main communication channel. What was captured was the communication between lunar and command/service modules which was indeed on VHF and very straightforward (no subcarriers). About Sputnik: That's a very different story. Mostly because of much shorter distance. About wavelength stretching: To my knowledge, only Doppler effect can stretch wavelength. Were referring to the wave front expanding with the square of the distance (the beam width)? Could you please clarify? Now for your suggestions: First, currently we do not have a modeller on the team so it would really help to have this request on GH for the future when someone can do that. Second, there are so many other antenna designs that are not covered in RT either. Some of them are quite interesting, like slot and helical antennas (used on early spacecraft) or phased arrays (on modern ones). Craft alignment has no effect on antenna aim in RT at the moment and that is intentional as it would require much more precise craft programming than the current flight computer can provide and it would also make RT too hard for most people currently enjoying it (I presume). Thank you for your suport and comments. It's good to have knowledge/views challenged so one can correct or ensure them. AFAIK, there are issues in these situations because both RT and MJ use the same part of KSP API which results in issues like control locks being overriden by each other. This is a long standing issue that has not been resolved yet and probably won't be in RT1.x branch. The RT2.0 re-based on top of CommNet should solve this, as the loss of control is now a stock feature and MJ should work with that correctly (if not, it would be an MJ issue). I think @TaxiService or @neitsa could comment on this further if you're interested in more details.

@diomedea: Thanks for the link to phased array. I remember reading about it before, but I forgot. The first space probe to use that kind of antenna was MESSENGER sent to Mercury. Also thank you for the kind reminder of actual rovers an their tracking antennas for directo communication to DSN. I also have to mention the Sojourner rover, that did not use any (too small). @NemesisBosseret: Tracking antennas: Both MER and MSL rovers have a low gain "omni" antennas for relaying data through satellites around Mars. Tracking antennas are used for communication directly with DSN. Planetary comms: I did not say I doubted the ability to communicate across the whole planet on HF. What I do have reservations about is data rates and sizes of diretional antennas in this band. I also have to repeat that modelling planetary radio communication is not a goal of RemoteTech, instead it's deep space probe communication. The "rules" for radio communication you mention seem to be relevant for Earth atmosphere. In vacuum radio signals of all frequencies travel exactly the same way and the only derioration above the travel distance (received power drops with the square of the distance) is caused by noise captured by receiving antenna that usually comes from planetary bodies (even Earth's radio pollution can be covered by that) which is not proportional to distance but receiver antenna directionality and aiming precision instead. Using bands like S, X or Ka gives much higher possible bit rates with the option of lower ones when the situation requires it, which is why they are being used. For example Voyager probes use X-band to talk directly to DSN and both can still receive commands and send scientific data. Obviously it requires the use of the biggest most powerful antennas in DSN (70m dish possibly arrayed with acompannying smaller dishes) Apollo's unified S-Band: If you're not convinced by the Wikipedia article, here is a source directly from NASA that they themselves claim to be the best source of information about unified S-band design. The situation you describe, of using Communotron 16 for transmission back to KSC (that would have to go through a relay satellite) does not seem very reasonable as there was a similar situation in reality when Galileo probe's main antenna failed to deploy and the communication had to go through low gain antennas. You can read more here. Now back to what RT does and does not. It does not simulate use of different frequencies as data sizes/rates in KSP are very arbitrary with little to no relation to real world. What it does simulate is the line of sight requirement of radio communication in deep space and delay caused by light speed travel of radio waves. Also the need to use power for the commsa to work. It also does not simulate other sources of delay like signal processing on both ends of a link nor does it claim to simulate planetary atmospheric communications as we do not know the poperties of Kerbins atmosphere in relation to radio waves nor do we know how Kerbals would use it. And even if we did, it would have much smaller impact on most gameplay compared to what is implemented in RT at the moment. If you have specific suggestions for improvement of RT, please state them clearly and directly, on our github if possible. BTW: It's radome not raydome. Enven google suggested it in the linked searches.

If it ever makes past the idea stage, it will be an extra module not included and certainly not active in a default installation, so no need to worry. Whether it's worth coding is something yet to be determined

@NemesisBosseret Tracking dishes: Can you please provide an example of a tracking dish mounted on a spacecraft? I'm no expert (not even close) nut I have yet to see any mention of such thing (not even on rovers). Also RT does not take physical position of the dish on the craft into accout anyway, so the tracking would be only cosmetic. Taking dish axis from the actual craft/dish position may be considered later in RT 2.0 development though as an extra difficult option. Delay based on type of connection: The planned framework for delay in RT 2.0 will allow for inclusion of other factors in addition to speed of light delay. Planetary comms: As KSP is mostly about exploring space, it seems reasonable to have communication mechanics focused on that. Also I'm quite sceptical about data bandwidth on frequencies required for ionospheric reflection (roughly <10MHz). There's a reson why live TV is not transmitted that way, but relayed through a satellite using C or Ku band. And any crewed mission in KSP needs a video downlink for the face cam. Apollo missions: I'll just point you >here< In general: It is important to understand that KSP is still just a game and it's relation to our (human) history of space exploration is not that tight. For example Kerbals start by sending other Kerbals into space before they even consider sending out probes. That suggests they do things differently. It is also important to note that any game mechanic in KSP (stock or modded) must strike some balance between percieved realism and playability (not to mention complexity of code, especially in case of mods). RT has no concepf of frequency, so it had to pick a behavior that would fit the most, which is based on S and X bands used for anything going past the Moon. RT 2.0 may include some frequency differentiation as an extra option. I hope I managed to comment on all your suggestions. It's not easy to follow several ideas mixed in a single big block of text.

As for keeping satellites in place, I think it makes a great idea for a new mod. This would be way out of scope for Remote Tech

I'd like to know more about your plans for implementation. At least for inspiration. What kind of range model you're using? Square root model woud do this, I think.

Relaying should be a feature, not a switch, so a core that can relay will still have all the standard features including proper communication as required to fly it. This will probably be implemented as a separate part module that will mark the vessel as relay-capable for our modified version of CommNetVessel, so it may allow creation of parts that would serve just as "relay computers". At least that's the plan. We're still in early stages of RT2.0 development, but unless we hit an unexpected roadblock, it seems this should make it into first release, whenever that happens to be. Also, in stock CommNet any relay antenna should work as a comms antenna as well, if I'm not mistaken. Haven't played around with that, yet.

In current versions of RT, there is no distinction between relay and direct antennas, every antenna on every vessel can relay. This comes mostly from the fact that so far RT is independent of CommNet and does not use any part of it. Instances of stock ModuleDataTransmitter are removed by MM patch in RT and CommNet is forced OFF. The Mode0 and Mode1 ranges are un- and deployed range and the antenna only consumes power when in Mode1. So there's literally nothing to be compatible with. A CommNet based RT is in the works, but it will be a while before it's released, even for testing. In it, we plan to include new logic for determining a relay. Instead of an antenna (which never made much sense to me) the probe core will determine relay capabilities of a vessel.

I didn't want to sound that defensive I just meant to explain why bother with conditions on commands and maybe discuss the reasons further. I myself tried kOS before and I liked the idea. But it required too much learning outside KSP and I just wanted to play the game. The idea of kOS is cool and it being available is awesome but It's hard to learn kOS by trial and error, unlike the rest ot KSP. Maybe I'll give it another try sometime.

I agree with @diomedea on this. Not everyone wants to use kOS, mostly because of the "a lot more" part making it a bit intimidating. As RT already has to handle commands sent to vessels, it seems like a reasonable idea to include simple trigger conditions that will suffice for many, even if it cannot be used to auto land a Falcon 9 first stage.

I am not aware if something like this being done in the history of our space exploration, but don't take my word on it, I'm no historian. But this concept seems so perfectly Kerbal, that I'll write it down for later as storing and sending commands further should be possible within the framework we're currently constructing for handling commands in RT2.x. Still, don't hold your breath

There is a stock module ModuleRelayEnabler in CommNet namespace that would be a much better candidate for inheriting. You just need to add the code for manually turning it on/off. Much cleaner way to achieve your goal.

Do you have the latest RT (1.8.2)? And does your vessel have an external antenna? I tested this with just RT and AsteroidDay and it works for me so if you keep having problems with the SENTINEL, let us know (GitHub issue is preferred).