Nibb31

Members
  • Content count

    5,483
  • Joined

  • Last visited

Community Reputation

2,960 Excellent

1 Follower

About Nibb31

  • Rank
    Flight Director

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Nibb31

    SpaceX moon landing.

    Yes, too cramped, poor landing visibility, and poor EVA capability. With its dedicated LM, the LOR mission profile was much more capable. Back to SpaceX, landing a Dragon 2 on the Moon would look a lot like the Apollo Direct Ascent vehicle I posted above. You would be better off landing the BFR. Note that a BFR lunar landing would also require several refuel missions before the TLI burn.
  2. Nibb31

    SpaceX moon landing.

    The early Apollo Direct Ascent mission architecture required the Nova rocket, which was much larger that the Saturn V. Basically it required landing the Apollo CSM onto the lunar surface, which required a much larger descent module, which required a much larger upper stage, etc... The Gemini lunar lander was never seriously considered. It was too cramped and would have been extremely awkward to provide landing visibility and to EVA from on the lunar surface.
  3. Nibb31

    Making your own code

    This is getting like talking to a brick wall. Any programming language needs something called an interpreter, which is a computer program that converts your personal language into commands that are understood by the hardware. How are you going to code that interpreter if you don't want to learn how to code ??? You learn how to code one. This probably requires several years studying computer science and various languages. By that time, you will have realized that there is no point in writing your own language. You cannot create your own computer language without learning to code first. It's as simple as that. Which is why people here keep telling you to get an Arduino or a Raspberry Pi and learn C or Python. Why are you asking for advice if you don''t you listen to it?
  4. Basically, because the Apollo program was cancelled. Schmitt was the only geologist in the group. Therefore, he had higher priority to fly an Apollo lunar mission. He was originally assigned to Apollo 18, but was bumped up to Apollo 17 when 18 was cancelled. The others were physics or medical specialists, whose specializations were obviously a lower priority for the lunar landings. Graveline resigned from NASA in 1965 before being assigned a mission due to his divorce (which would have caused some awkwardness at NASA in the 1960's). Michel resigned from NASA in 1969 when he realized he wouldn't get to fly on Apollo. Garriot, Gibson, and Kerwin stayed at NASA and got to fly to Skylab. Garriot flew again on the Shuttle. Even though they never landed on the Moon, they ended up spending more time in space than Schmitt. https://en.wikipedia.org/wiki/NASA_Astronaut_Group_4
  5. Nibb31

    Making your own code

    Then writing your own computer language probably isn't the easiest way to familiarize yourself with them. Typically, the aerospace industry uses embedded computers that use C and Ada. They are designed for reliability, readability, and certification, which is expensive. This means that once the code is properly validated and certified, then they will avoid touching it unless it is absolutely necessary. There are several layers to what you want to do: - First you need some sort of low-level bus control software between the computer hardware and the flight controls that you want to activate (control surfaces, motors, hydraulics, engines, etc...). - Then you need to code a layer that will convert functions in the code into those hardware output commands ("engine throttle 35%" means reconfiguring the turbopump, opening or closing valves, checking that values are valid, etc...) - Then you need to the code the layer that takes input from the controls and converts those commands to call the functions above. The control can be a physical button or lever, a series of sensors, or a programmed flight script. The script parser and interpreter, and designing the syntax, are probably the easiest bits to code once you have laid out the proper functions to call. Of course, if you have zero coding experience already, this is all going to be extremely difficult. Sounds like the "verb" + "noun" command architecture for the Apollo AGC.
  6. Nibb31

    Dissolving the fermi paradoxon

    The values entered into the Drake equation are based on guesswork. Therefore any calculations using those values are about as useful as rolling a dice.
  7. Nibb31

    Space Station construction

    They can still close hatches and seal off modules if there is a leak or a fire. In this photo, you can see the door is stored on a pair of rails so that they can slide it down and close the hatch. (it actually looks like this particular astronaut is about to have an unfortunate accident involving a treadmill, and a rogue pair of scissors)
  8. Nibb31

    Space Station construction

    As Magnemoe said, the US modules are connected via CBM ports and permanently bolted, but there are also external and internal connections for coolant loops, cables, fluids, etc... Removing all those connections isn't impossible, but would be stupidly long and difficult process involving many EVAs. EVAs are complicated, expensive, and risky, so they are to be avoided as much as possible. However, NASA has relocated the Leonardo PMM module (ex-MPLM) and the PMA adapters (docking ports), which are less permanently installed. Probe and drogue can usually be disconnected without any problems, but they might also have some external power and fluid linkages that would need to be disconnected first. Note that on Mir, most of the modules were disconnected and moved around at one point. Each module docked to the Mir Core using the central port. Then they were moved with a robotic arm to the radial ports. Presumably this is because only the central port was equipped for automatic docking. By the way, Zarya is actually a US module. It was purchased by NASA from the Russians to avoid developing their own service module and it uses APAS to connect with Unity/Node 1.
  9. Nibb31

    Space Station construction

    Mir and the Russian section of the ISS, were built that way. This is the simplest method, but can be seen as wasteful, because each module is its own autonomous spacecraft, and therefore expensive, with manœuvering engines, RCS, docking computers, solar panels, comms, etc... The US section of the ISS was built with the Shuttle. Each module is a "dumb canister" that cannot survive on its own but is much simpler and cheaper. The drawback is that it required an expensive Shuttle flight and manual assembly. The Shuttle brought up each module and assembled it with the Canadarm. An alternative is the reusable space tug. You launch a module into orbit, then you send a reusable tug to retrieve it, bring it to the station, and dock. Then you can release the tug for the next module. The drawback of this is that you need to refuel the tug, which makes operations more complex.
  10. Nibb31

    TKS/FGB and Almaz's engine number

    Almaz and TKS are different vehicles. Almaz was based on the DOS design (Salyut, Almaz, Mir core, ISS Zvezda...). TKS became the FGB modules (All the other Mir modules, ISS Zarya, etc...). TKS had two main engines, they are the small blocks above and below the VA capsule, noted 3 in the diagram below. In orbit, the TKS flies "backwards": the "front" is where the docking apparatus is located. Later FGB modules had a different arrangement. The engines were placed on the main docking end:
  11. Nibb31

    Future Surface to Orbit travel?

    Space Elevator would be slow, expensive, and not scalable. I don't see how it could be competitive against BFR-type chemical rockets.
  12. Nibb31

    NASA SLS/Orion/Payloads

    RS-25 isn't restartable or throttlable, so there is no way you are going to land a core on two of them (out of four). To make SLS reusable would need totally different engines, a totally different core, totally different boosters, and therefore a totally different architecture.
  13. It would be a transfer of competency. There will be no Viper starfighters or Space Marines. USAF Space Command, USAF ASAT capability, some parts of NRO, Navy, and other arms would be transferred into this new Space Force. Anything else is presidential fluff, and the whole idea is being pushed back by the Pentagon and Congress as it would likely increase costs and reduce operational efficiency and coordination capability. For example, US ASAT capability is based on USAF or Navy assets that are also used for other missions.
  14. Nibb31

    Supersonic reusable microsat LV

    You mean "continue"
  15. It would really just be a reorg of the USAF Space Command and some Navy and NRO assets into a single structure. This is a presidential order that nobody really asked for and it needs Congress to actually approve it and allocate a separate budget to this new arm. My bets are that it won't happen.