maja Posted February 27, 2017 Share Posted February 27, 2017 44 minutes ago, TaxiService said: Thank you for letting us know on this error! (More specifically, the error seems to say that one or more parts of RoverDude's MKS are deliberately deactivated until as some milestones of a career are achieved?) I think, that this has something to do with the latest integration of the Ground Construction mod to the MKS. These three parts has the GroundWorkshop module. @RoverDude can shed some light on this issue. Quote Link to comment Share on other sites More sharing options...
RoverDude Posted February 27, 2017 Share Posted February 27, 2017 Yeah probably want to take this over to the GC thread and ping @allista on it Quote Link to comment Share on other sites More sharing options...
Yamori Yuki Posted February 27, 2017 Share Posted February 27, 2017 @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. Quote Link to comment Share on other sites More sharing options...
AlexisBV Posted February 27, 2017 Share Posted February 27, 2017 Did some research and could not find an answer, so here's my question: is there anyway that brakes on a rover can be applied automatically if connection is lost? Specifically in conjunction with MechJeb's rover autopilot. I know the autopilot has "Brake on energy depletion" and "Brake on pilot ejection", but even with both checked the rover just rolls away with no brakes if it has no connection... I was hoping that "brake on pilot ejection" would work, but I guess it's looking for some other flag. Quote Link to comment Share on other sites More sharing options...
cyberpunkdreams Posted February 27, 2017 Share Posted February 27, 2017 30 minutes ago, AlexisBV said: Did some research and could not find an answer, so here's my question: is there anyway that brakes on a rover can be applied automatically if connection is lost? Specifically in conjunction with MechJeb's rover autopilot. I know the autopilot has "Brake on energy depletion" and "Brake on pilot ejection", but even with both checked the rover just rolls away with no brakes if it has no connection... I was hoping that "brake on pilot ejection" would work, but I guess it's looking for some other flag. This doesn't exactly answer your question, but you might want to consider Bon Voyage if you work with rovers a lot. It's the best way to do long distance travel with them. Doesn't help you if you're just driving around for fun though, I know... Quote Link to comment Share on other sites More sharing options...
NemesisBosseret Posted February 28, 2017 Share Posted February 28, 2017 @Yamori Yuki tracking dishes :rgr Planetary comms: RF propegation. Its the same planet side as it is in space. It reacts the same. Degregation occures with higher freq always. Even in space going thru solar flares out side our solar system solar flares etc. Any high ionozation even traveling from million of light years away will cause it.... Space actually has alot more of it than planet side, planet side you get cases of RF ducting(RF traveling hundreds if not thosands of miles and accurately picking up signals or over the horizon radar). But thats an entirely different ball park of science phenomenon that ill save for a later date. Data rate for HF just depends on ur code ur using. Fast algorithms with pre built in instructions you can transmit heaps of information in seconds. A very primitive version of this can be found. Just look up Q and Z signais. 3 letter codes aka the international radiomen language http://dcasler.com/ham-radio/acp-131b-q-signals-and-z-signals/ or you can also read annex k. (annex kilo) but be forewarned you might end up quiting ksp and get sucked into a book for the next year or two Apollo missions: https://en.m.wikipedia.org/wiki/Radio_frequency the S band also known as UHF/SHF Boundary band. .. Funny thing Is that S band freq used by apollo is just high UHF. not really S band , s band is more or less some crack pots idea of a junk freq range with zero satilitie communications experiance .... UHF covers all the way to 3 gigs and its why i hate these civilian bands you keep stating..... There retarded. Please use actual frequencies numbers not the civi letter code its garbage or Use nato bands like anyone who actually knows communications. Is going to use. Its less confusing just like metric is less confusing than imperial... I know its how they teach you in school... But its wrong. Its also why nasa hired a few guys like me over the years with real experience with this stuff to help with there communication issue.... Galileo: people like me refined the gain to pick up the omni antenna signal earth side and fine tuned the omni to pick up us. Funny thing about space.... The bigger your ears the more you can hear, the bigger ur eyes the farther you can see.. The reason the dishes on deep space craft is so big is so they can catch the degregated milimeter signal that has degregated to the size of a basket ball court by the time it reaches them..... The RF wavelengths have streched. Instead of fine tuning a more robust signal nasa went with the tim allen approach of "more power" and look at there funding now.... Wonder why civilian contractors can do it cheaper..... Hmm... But something interesting to read http://www.arrl.org/eavesdropping-on-apollo-11. VHF comms 30mhz to 300mhz Or https://en.m.wikipedia.org/wiki/Sputnik_1 HF transmitions where heard across the globe thru our atmosphere. Lol and to finish thank you for the spelling correction... I was tired and using my cell phone transmitting in this awsome S band freq the apollo missions used(2.6 to 4.5 ghz). So forgive my 60 year old tech for auto correcting my sleep deprived spelling and possibly being unable to clearly transmit thru stuco walls while my low freq yelling can travel thru....(yes that is an accurate explaination of frequency and communication on a much dumbed down level) but as to the github request... Ill try. But in case not Simple lamens terms . 1.Add small 3 to 6 inch dishes covered by a radome "enven" google will have some good examples for ya lol that can transmit on the UHF and EHF spec that can hit a satilite in space at geosynchronous orbit/ geostationary. They exsist in real life why not have something similar in ksp? Most if not all omni dont reach geostationary when a covered dish planet bound would. 2. Add maybe an auto target align sas script to target and align its comm hoist. This really cant be that hard to script write. But then again it could be kraken prone. 3. Keep up good work on remote tech, makes ksp a million times better Quote Link to comment Share on other sites More sharing options...
Mikeloeven Posted February 28, 2017 Share Posted February 28, 2017 (edited) speaking of mechjeb's autopilot I have been having an issue with RT and mechjeb. I think this is a bug because it doesn't make sense in terms of how flight computers work. If the ship temporarily looses connection while mechjeb is executing a maneuver or series of maneuver nodes RT will activley block mechjeb's inputs causing the ship to stop responding mid maneuver and not execute any further queued maneuvers. I think its safe to assume that as soon as you tell mechjeb to execute a planned series of maneuvers that the maneuver data has already been sent to the system and while you would not be able to make manual corrections or send further instructions during a signal loss, RT should not interfere with mechjeb's ability to execute a planned series of maneuvers that were queued while the connection was still active. Edited February 28, 2017 by Mikeloeven Quote Link to comment Share on other sites More sharing options...
Yamori Yuki Posted February 28, 2017 Share Posted February 28, 2017 (edited) @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: Quote The story discussed how Baysinger recorded 35 minutes of conversation from VHF signals transmitted between astronauts Armstrong, Aldrin and Collins (he did not attempt to pick up the encoded S-band signals from the main Moon-Earth communication link). These 35 minutes included the time during which President Richard Nixon transmitted a message of congratulations to the astronauts. 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. 10 minutes ago, Mikeloeven said: speaking of mechjeb I have been having an issue with RT and mechjeb. I think this is a bug because it doesn't make sense in terms of how flight computers work. If the ship temporarily looses connection while mechjeb is executing a maneuver or series of maneuver nodes the ship will stop responding mid maneuver and not execute any further queued maneuvers. I think its safe to assume that as soon as you tell mechjeb to execute a planned series of maneuvers that the maneuver data has already been sent to the system and while you would not be able to make manual corrections or send further instructions during a signal loss, RT should not interfere with mechjeb's ability to execute a planned series of maneuvers that were queued while the connection was still active. 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. Edited February 28, 2017 by Yamori Yuki merged posts ... Quote Link to comment Share on other sites More sharing options...
Mikeloeven Posted February 28, 2017 Share Posted February 28, 2017 any ideas when the 2.X branch is coming out ? Quote Link to comment Share on other sites More sharing options...
Yamori Yuki Posted February 28, 2017 Share Posted February 28, 2017 2 hours ago, Mikeloeven said: any ideas when the 2.X branch is coming out ? It's hard to say but as it is now we may or may not make it in Q2. Quote Link to comment Share on other sites More sharing options...
TaxiService Posted March 1, 2017 Share Posted March 1, 2017 (edited) 19 hours ago, Mikeloeven said: any ideas when the 2.X branch is coming out ? To expand Yamori's post, the CommNet in KSP 1.2 has almost everything the RemoteTech 1.x branch requires in order to manage a communication network of vessels. CommNet has nodes, links, paths, com-modules and range models. Every vessel (with or without antennas) has CommNet variable (mesh of RT SignalProcessor, FlightComputer and others). CommNet has all ground stations and occlude info of every celestial body. Even, KSP has the new autopilot (SAS + pilot skills). So basically, CommNet has the entire infrastructure laid down, removing the need for RemoteTech to operate its own increasingly-complex infrastructure (huge fraction of RT codebase is dedicated to this). With this out of our way, we the RT team have a lot of free rein to design and build multiple non-infrastructure features, that are long requested/deferred/new (link). An antenna simulator on science, power and range data Next generation of antenna system (you saw the detailed exchange between Yamori and NemesisBosseret above; RT 1.x has a binary antenna system - 100% or 0% signal strength) UI Visualization of colored icons, vessels, range edges etc Queue of active and timed commands (gears, landing, fire at 250m alt, toilet flushing) In simple words, RT 2.x branch is sort of a "new" mod with some RT 1.x parts, piggybacking on CommNet infrastructure. We are currently developing new features, which can take some time. Of course, we are not neglecting the RT 1.x branch. Since the last release RT 1.8.4, some bugs are fixed and small improvements are added. Edited March 1, 2017 by TaxiService Quote Link to comment Share on other sites More sharing options...
doktorstick Posted March 1, 2017 Share Posted March 1, 2017 How do you handle landing on bodies outside of Kerbin's SOI with RemoteTech? As-is, I've manually landed remote probes on Mun and Minmus, and my remote probes are approaching Eve and soon I'll need to have then land on the planet and its moon... with 40+sec of signal delay. Quote Link to comment Share on other sites More sharing options...
cyberpunkdreams Posted March 1, 2017 Share Posted March 1, 2017 F 1 hour ago, doktorstick said: How do you handle landing on bodies outside of Kerbin's SOI with RemoteTech? As-is, I've manually landed remote probes on Mun and Minmus, and my remote probes are approaching Eve and soon I'll need to have then land on the planet and its moon... with 40+sec of signal delay. For Eve, a parachute landing is probably fine? Otherwise you either need kOS or an advanced probe core that gives you local control. Quote Link to comment Share on other sites More sharing options...
doktorstick Posted March 1, 2017 Share Posted March 1, 2017 1 hour ago, cyberpunkdreams said: ...an advanced probe core... Is this something that's in stock/RemoteTech? I've not unlocked the full tree nor really explored ahead to see what's available. Quote Link to comment Share on other sites More sharing options...
cyberpunkdreams Posted March 1, 2017 Share Posted March 1, 2017 1 minute ago, doktorstick said: Is this something that's in stock/RemoteTech? I've not unlocked the full tree nor really explored ahead to see what's available. It's in stock: http://wiki.kerbalspaceprogram.com/wiki/Probodobodyne_QBE There may be others that do this as well? It's quite high in the tech tree. Quote Link to comment Share on other sites More sharing options...
Calvin_Maclure Posted March 1, 2017 Share Posted March 1, 2017 1 hour ago, cyberpunkdreams said: It's in stock: http://wiki.kerbalspaceprogram.com/wiki/Probodobodyne_QBE There may be others that do this as well? It's quite high in the tech tree. I dont see how this will allow you to overcome time delay from RT. Quote Link to comment Share on other sites More sharing options...
cyberpunkdreams Posted March 1, 2017 Share Posted March 1, 2017 38 minutes ago, Calvin_Maclure said: I dont see how this will allow you to overcome time delay from RT. Because it gives you local control, as if there was a kerbal on board. I'm pretty sure that's stock for this core, and not just given by a mod I have installed. Quote Link to comment Share on other sites More sharing options...
NemesisBosseret Posted March 1, 2017 Share Posted March 1, 2017 4 hours ago, doktorstick said: How do you handle landing on bodies outside of Kerbin's SOI with RemoteTech? As-is, I've manually landed remote probes on Mun and Minmus, and my remote probes are approaching Eve and soon I'll need to have then land on the planet and its moon... with 40+sec of signal delay. I believe you got two options but someone correct me if im wrong. A command ship in orbit acting as a communications station with X amount of crew on board..... Or.... Plan ur decent via maniuver nodes and the RT flight computer like NASA does in real life and pray it works. There is mods out there that could automate ur landing like mcjeb and landertron. Suggest you check them out. Quote Link to comment Share on other sites More sharing options...
Nathair Posted March 1, 2017 Share Posted March 1, 2017 1 hour ago, cyberpunkdreams said: Because it gives you local control, as if there was a kerbal on board. Not for me, unless I misunderstand you. Behaves just like any other probe core as far as I can tell. Quote Link to comment Share on other sites More sharing options...
cyberpunkdreams Posted March 1, 2017 Share Posted March 1, 2017 2 minutes ago, Nathair said: Not for me, unless I misunderstand you. Behaves just like any other probe core as far as I can tell. Well, I've got something proper weird going on then! It's just this probe core that behaves this way for me. It's always been this way, across multiple career games and mod set-ups. I don't even really want it to be honest, as it does feel weird... Quote Link to comment Share on other sites More sharing options...
NemesisBosseret Posted March 1, 2017 Share Posted March 1, 2017 @cyberpunkdreams @Nathair @doktorstick check RT guides and tutorial page. On there there is one probe core that can act like a command station, command stations are also explained a bit more. Quote Link to comment Share on other sites More sharing options...
thunder175 Posted March 1, 2017 Share Posted March 1, 2017 (edited) 1 hour ago, cyberpunkdreams said: Well, I've got something proper weird going on then! It's just this probe core that behaves this way for me. It's always been this way, across multiple career games and mod set-ups. I don't even really want it to be honest, as it does feel weird... I'm guessing its an addon core from a mod? It might not have an MM patch for RT compatibility. Make sure there is an entry for it that looks like the below, which I had to add manually for the latest Github beta version of Coatl due to there not being an entry for RT compatibility with the Vorona core. EDIT: I just saw your post about this being on the stock QBE. Do you have any other mods that could be overwriting MM patches for probe cores? Spoiler @PART[ca_vor_core]:AFTER[CoatlAerospace]:NEEDS[RemoteTech] { %MODULE[ModuleSPU] { } %MODULE[ModuleRTAntennaPassive] { %TechRequired = unmannedTech %OmniRange = 3000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } } Edited March 1, 2017 by thunder175 Quote Link to comment Share on other sites More sharing options...
cyberpunkdreams Posted March 1, 2017 Share Posted March 1, 2017 6 minutes ago, thunder175 said: EDIT: I just saw your post about this being on the stock QBE. Do you have any other mods that could be overwriting MM patches for probe cores? Reveal hidden contents @PART[ca_vor_core]:AFTER[CoatlAerospace]:NEEDS[RemoteTech] { %MODULE[ModuleSPU] { } %MODULE[ModuleRTAntennaPassive] { %TechRequired = unmannedTech %OmniRange = 3000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } } Quite possibly, but I have no idea what it could be... Quote Link to comment Share on other sites More sharing options...
TaxiService Posted March 2, 2017 Share Posted March 2, 2017 (edited) 13 hours ago, cyberpunkdreams said: Quite possibly, but I have no idea what it could be... I think I know what you are talking about. Take a look at this issue and is it what you means? Autopilot/SAS commands on all probes are not delayed by Remotetech. A fix to this issue is already being worked out. Edited March 2, 2017 by TaxiService Quote Link to comment Share on other sites More sharing options...
Mikeloeven Posted March 2, 2017 Share Posted March 2, 2017 (edited) Is it normal for antennas to stop working underwater ? I recently started working on oceanic probes added by a mod however the second they splash down anywhere on kerbin and start sinking the antenna goes out and I loose the probe? I was under the impression that connections could be made to the space center pretty much anywhere on or around kerbin Edited March 2, 2017 by Mikeloeven Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.