Search the Community

Showing results for tags 'kerbnet'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • The Daily Kerbal
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


Location


Interests

Found 13 results

  1. I was browsing the interwebs a while ago and found this interesting communications network design that works around the annoying orbital drift bug (is it a bug? I'm not sure) by utilising four comsats in eccentric orbits instead of the normal synchronous orbits. I couldn't find where I saw the original diagram, so I knocked this up in five minutes on Paint - I hope it gets the point across. (Note that this is looking at the planet from directly above the north or south poles). There's a few things I was wondering about this setup: 1. What is the probability that you are in contact with the space centre? 2. How likely is it that you are in contact if the orbits are more eccentric or less eccentric? 3. What are the advantages and disadvantages of this setup?
  2. Ok so as you know from the title my kerbnet dose not seem to work correctly. Every time I pres kerbnet access I get a screen saying it’s offline. I have 100% signal strength and direct connection to the space center. As far as parts that would influence this I have probodobodyne for a probe body (that took to long to spell) and two narrow band scanners the only mod I have running on this is TweakScale which can change the size of the parts but I don’t think that would influence it thanks for even reading this
  3. Hi guys, I've been setting up evenly spaced triangle orbit satellites at 120 degrees for my network and can get them at exactly at 120 from each other without any deviation. But every six months-year the phase angles either rise or drop by .01 degrees and decades later my little triangles are all messed up. I know it's because my apoapsis and periapsis are just barely not matching but damn it's hard to get the apoapsis and periapsis that precise. Has anybody else had this issue?
  4. I have a problem. Recently, I launched a relay into stable polar orbit around Kerbin, and even though I'm below 600,000 km AND I have the M700 Survey Scanner, I still can't seem to cycle the Kerbnet view mode to resource mode. How can I access resource mode in Kerbnet? I'll post some screenshots below of what I'm trying to get across. This is the mode I want to see: Resource mode. This is a picture of my satellite: This is my satellite. This is my connection to Kerbin and my altitude: This is some information.
  5. Hi, I am currently having an issue with the KerbNet feature as of the 1.3 update. Prior to the update, I could use KerbNet with any probe body with no problem. Now, all I get is this when I open up the access window: The only mods I have installed are Kerbal Alarm Clock and a planet pack, but KerbNet worked fine with these same mods in 1.2.2. Does anyone know what I could do to fix this? Thanks in advance! edit: solved, kopernicus is currently having some issues with scanners, just gonna have to deal with it.
  6. Hello again fellow Kerbals. I have a rover that I have been testing around the KSC and I have been trying to learn how to use the Kernet aboard my Rovemate. I have located a "?" mark on the Kerbnet that when I am on top of it just happens to sit right in the middle of my crawlerway. My questions are: 1. How do I interpret this map? 2. How do I figure out what the question mark is? 3. What can I do with this info? Here is a picture:
  7. Ncog Nito

    Kerbnet

    Hello All. I have seen threads mentioning the Kerbnet and how it detects anomalies. I have a rover with a rovermate probe body and I have seen where this should allow me to use the Kerbnet. Is this a mod? If not how do I access it?
  8. Step 1: put a satellite in Kerb-o-synchronous (geostationary/geosynchronous) equatorial orbit. Step 2: once in desired orbit, push 'V' until in "chase camera". Step 3: play your favorite space themed ambience music. Step 4: push F2. Step 5: profit. Working on putting a little video together to share here shortly. It's times like these that remind me how much I appreciate this game and its developers. 400+ hours deep and it's the little things.
  9. Hello, So far the farthest I've ever been in KSP is a Mun landing, Before going to Minmus I plan on starting some sort of network around Kerbin, But I don't know how to start one. I to lonely
  10. The Boffins have not been idle despite it having been a long time since the Circus did anything. No, they've been hard at work testing and tweaking stuff for the next chapter of the Glorious Kerbal Space Empire. Their current project is to develop a kOS script to facilitate the deployment of what they call "Moonsats". In the Circus concept of communications networks (see the link in my sig), there are 2 general species of commsats: Main Relays, which have huge antennae and are in highly eccentric polar orbits over the central body in each planetary system, and Moonsats, which are in moderately low circular orbits, usually but not necessarily around moons of the central body. There usually needs to be more than 1 of these latter per "moon", and they need to be spaced neatly, and that requires more math than the Boffins want to do manually. Thus, the goal was to make KAL9000 (actually the name of the computer part in kOS) do crunch the numbers for them . Anyway, the project has gone from the drawing board to partial implementation and successful completion of early milestones in the course of today. The Boffins are feeling a little proud of themselves so decided to show off what they've done so far. And here it is: Really, that's all it does right now, just calculate and display those 5 particular numbers, only 2 of which are really important at the moment. But that was the main challenge. The rest of the project should be somewhat simpler as it traverses known ground. Today the Boffins had to learn more about the "anomalous rectums" (actual technical term) of orbits than they ever wanted to know . There's a non-negligible amount of code and a lot of research behind this simple display. The idea of the whole project is as follows: A carrier vehicle (CV) with 3 moonsats aboard gets into an elliptical orbit at the desired inclination around the body the Circus wants to hang a network on. At this point, the kOS script is activated. The kOS script figures out a good altitude for the moonsats to orbit the body and adjusts the CV's Pe to that altitude. The kOS script determines the orbital period for a circular orbit at this altitude, then multiplies that by 1.33333 to get the desired orbital period of the CV. The kOS script calculates the Ap needed by the CV to have that orbital period and adjusts the CV's Ap as needed. Once so adjusted, the CV releases 1 moonsat per orbit, each of which then circularizes at the Pe of the elliptical CV orbit. Because the CV's orbital period is 1/3 longer than that of the moonsats, each time it or a released moonsat reaches Pe, it will be 1/3 of an orbit behind the previous moonsat, so they end up evenly spaced and able to see each other around the body. To accomplish this, the Boffins broke the project up into phases: Phase I: Develop the basic algorithms for computing the required orbital parameters, in such a way that the same script can be used at any body with a reasonably large SOI. Just print these numbers on the screen and test their validity by performing the necessary maneuvers manually. This is actually the only important phase because the system is workable at this point. The later phases are gravy. Phase II: Add the ability to deploy n >= 3 satellites, and add automation so the CV performs all maneuvers itself. Phase III. Write a separate program for the moonsats so they can tweak their own orbits automatically. Today, the Boffins are please to report that Phase I is complete! It's that output which appears in the pic above. The process starts by determining a "good" altitude for the moonsats. This has to be high enough that they can see the adjacent moonsats sharing the orbit without the planet in the way, plus have some margin of error for imprecise maneuvers getting there. For the 3-moonsat problem, this altitude is determined as follows: The desired quantities are the line CS (for calculation purposes) and also CS minus the radius of the planet (orbital altitude for maneuvering purposes). The length of the line CF is arbitrary, whatever you think gives enough clearance between the edge of the planet (and atmosphere, if present) and the LOS between adjacent moonsats. In Phase I, the Boffins chose 120% of the body's radius. This turned out to be just a tad too short in practice, so will be increased to 150% in the next round of testing. In any case, for the 3-moonsat problem, Triangle CFS is a 30-60-90 right triangle so with CF given, calculating the length CS is just 1 trig function away. The next step is to calculate the orbital period for a circular orbit of radius CS. Just plug the numbers into Kepler's 3rd Law: T = SQRT[(4 * π2 * R3) / (G * MP)] where T is the period, R is CS, G is 6.673 x 10-11, and MP is the mass of the body you're orbiting. Simply multiple this value by 1.3333 to get the period of the CV/s desired elliptical orbit. It was at this point that the Boffins started running into all the "anomalous rectums" and thought they were going to have to do a bunch more calculations using them to figure out the CV/s desire Ap by way of the semi-major axis. But fortunately, the Boffins figured out a shortcut after a chance reading of a footnote buried deep in dense pages of complex equations. That life-saving footnote said this: "A circular orbit with a radius equal to an elliptical orbit's semi-major axis has the same period as the elliptical orbit." The Boffins already now had the period of the elliptical orbit so could plug that back into Kepler's 3rd Law (above) rearranged to solve for R, which in this case would be the semi-major axis of the CV's elliptical orbit. R = [(T2 * G * MP) / (4 * π2)]^(1/3) Then, because the planet is at one focus of the ellipse, the altitude of the CV's desired Ap would simply be: Ap = [( 2 * SMA ) - CF] - the body's radius. Wow. That wasn't so hard, thanks to the shortcut Anyway, with all these numbers determined, the script simply printed them out as shown above. All this worked fine at Kerbin in an equatorial orbit but to really test Phase I, the Boffins sent a wad of 3 moonsats to Mun and had them arrive with a 60^ inclination. Here they all are still attached to the CV en route to Mun. And here they are being deployed, all being flown manually using the numbers calculated by KAL9000 using the script. You can see the CV is in a slightly elliptical orbit with the 1st moonsat in place and the next in-process. With all 3 moonsats in place, the Boffins de-orbited the CV. As it turns out, 2 of the moonsats can't quite see each other and the others are borderline due to their orbits being a shade too low. As mentioned above, fixing this is just tweaking 1 scalar value so really isn't important here. What is important is that the Boffins managed to code this script without any egregious logic errors, despite not knowing much about fancy orbital mechanics, and that the algorithms work well enough to provide good results even with substantial rounding errors (for clarity in the display of the numbers) and the imprecision of manual flying. So now the Boffins are celebrating with their traditional whiskey and wondering if it's even worth the trouble to go on with Phases II and III.
  11. Two questions about different scanners; 1) When you use KerbNet on some of the more advanced probe cores, they have the ability to detect anomalies. How do the mechanics of this work? Is there a one off chance of detecting an anomaly the first time you fly over or land in a new biome or does KerbNet recheck on each orbit/touch down? 2) I've been using a Surface Scanner to keep track of my position on my Mun Rover as it travels towards the South Pole. The display looks something like - Biome: Highlands, Lat 63.484 S [-1.108 N] Lon 140.008 E [2.444 E] . . . . . . What do the figures in the square brackets after the Lat and Lon mean?
  12. So, I had dabbled in SCANsat prior to 1.2, but now that Kerbnet is here I'm quite content with the stock solution. I'm presently living happily with Kerbin and Mun each having a triplet of relay satellites. Having over a dozen probes other spacecraft with probe cores, sometimes anomalies show up... And sometimes they don't. It seems as though one given probe sees a handful of them, another probe might see the same ones or different ones. I found one on the Mun and landed near it - the lander probe core never saw it no matter how close it was, but the surveyor that marked it with a waypoint spotted it from the SOI change on. I'm wondering if this is limited to a vessel or a core. I.e. if I have 30 probe cores on one craft, am I more likely to find more anomalies, or would 30 separate probes do the trick? Does anything reset them so it's prudent to check again later? Do different cores have better odds? Do the old ore survey scanners come into play? Why isn't there a KSPedia page that gets me pointed in the right direction with definitive answers? Despite the rant, I'm mostly just curious. I'm excited to start finding some of the easter eggs I've never seen for myself, but I just wonder what it'll take to be sure I've got them all. Prior to 1.2 I've only ever spotted the closest few to KSC and one Mun arch. Today I've found the Armstrong Memorial with the help of my probes - yay!
  13. kOS-SCANsat is an Addon to kOS kill Kerbals in new and exciting ways. It allows you to use the inaccurate data provided by a low resolution scanner to be used for mission planning**. It is designed to provide a "realistic" way to plan your missions and forces*** you to scan your landing side before you send a lander. Features: Low and High resolution altimeter scans Biome scans Resource scans slope data (and highly inaccurate slope data for low resolution scans) KerbNet Scanning of the current vessel. (only for biome and altimeter) ** you should bring a KerbNet compatible scanner with you, so you can prevent the worst. *** actually it doesn't remove the magical geoposition:terrainhight suffix, but using that is now considered cheating Requirements: KSP 1.3.1 kOS 1.1.5.1 SCANsat Full Documentation: Documentation of the API Downloads: Get the latest release here Source code is here