orbiternassp / nassp Goto Github PK

All of the heaters in the LM are currently just connected to radiators and effectively do not do anything. As the systems are made to generate heat for the glycol loop, the LM active heaters need to be looked at and wired up appropriately to the systems themselves and either radiators or the glycol loop, and then wired for proper power draw and subsequently to the SCEA for temperature monitoring.

As the title states, having the ECS page of the PAMFD open in the CM, and then switching to the LM, causes a CTD, and throws an exception in saturn->GetECSStatus(ecs);

There are a lot of compiler warnings in the code as it stands now. They should be cleaned up before the release.

Someone has made start/stop sounds for the suit compressor a long time ago.
This needs to be implemented.

http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2686

This is more as reminder to myself, I keep forgetting. :P
Of course, if you feel particularly motivated, feel free to add them.

Systems modelling to enable failures and breakage due to mismanagement.

The ML has hardcoded pad coordinates for LC39A, and when moved to 39B for Apollo 10 in it's scenario file the swing arms do not function.

The LM is eerily quiet right now with no system sounds compared to the CM. Astronauts reported the primary noise in the LM was the glycol pumps. I believe we can comb through some water pump sounds and find one that fits unless anyone has an idea of what they should sound like (I imagined higher pitched muffled droning?).

Additionally the suit fans should probably make a little bit of noise when on, something similar to the CM cabin fans, perhaps?

A few displays on the LM panel have spelling errors. Two that stand out are the AGS (spelled AQS) circuit breaker and the EXT LTG switch (center position should read OFF not ON). There may be others as well.

Additionally, a few items are needed such as the color bands on the temperature display, a panel for the utility lighting (code is in place just needs a panel), and a few switches are still inaccessible when switching to another panel where they are visible.

Documentation for flying Apollo 7 and 8 must be generated. This includes checklists for the checklist MFD.

Currently the simulated SPS engine does not have engine-on delay, thrust buildup, engine-off delay and thrust tailoff. The padloaded value for the thrust tailoff time (ETDECAY) is set to 0. However, this number is only used by the AGC for maneuvers of six seconds or longer. For maneuvers between one and six seconds the known behavior of the SPS is used to calculated the shutdown time before ignition. The engine-on delay and thrust tailoff cancel each other out to a certain degree, so this only leads to an overburn of up to 2 ft/s. For maneuvers of less than one second the assumed minimum impulse behavior of the SPS is used to calculate the shutdown time. Here the overburn is more significant and can reach up to 4 ft/s.

This issue is relevant for the EMS DV setting on the Maneuver PAD and the two minimum impulse maneuvers executed during Apollo 7. These maneuvers can still be done (with an overburn), so there is no immediate need to solve this issue for the next release.

Hi all,

Using the actual Orbiter2016 branch I get the following error followed by CTD when I try to go down to LEB:

Seem to me the problem caused by a 30. Mar change in the saturnpanel.cpp (commit 7a5c7e4), in which the CSM MFD-s (4 in the LEB) were resized. The two MFDs under the main panel are fine anyway.

Reverting the changes in the saturnpanel.cpp solved this problem for me, so I suggest doing something similar in the active branch as well.

Cheers,
Gergely

Rotary switches in the LM (and the CM, just change the behavior of the class) should be changed so that the new position does not snap to the position clicked, but rather through all positions until the desired position is reached, similar to that of a three position switch. While this was convenient, it messes with checklist flows which plan for and anticipate cycling through other positions to get to the desired one.

For example, in the LM glycol pump test, a comp light is expected when cycling from SEC to Pump 2, however since clicking Pump 2 makes the switch select it right away, you do not get the expected results.

Implement a 3D virtual cockpit like that of SSU.

Right now rudimentary tape motion control is simulated and nothing else. The DSE should actually record the PCM telemetry to a file in the orbiter directory. This would enable the use of DSE for debugging later - If someone reports a systems simulation issue, we could ask them to reproduce it with the DSE recording and then send us the DSE file. Enabling MCC to remotely control the DSE through the uplink would even allow the MCC software to identify abnormal conditions, make a DSE dump of it, then package the DSE dump with an error report file for investigation.

This would be somewhat dependent on PCM system work to implement the unimplemented parameters (which would be required before tackling Issue #13 anyway) in order to make the recorded data actually useful.

Documentation for flying Apollo 9 and 10 must be generated. This includes checklists for the checklist MFD.

MCC must be able to save and reload its state.

MCC should support generating PADs/uplinks for all major maneuvers in the Apollo 7 and 8 missions.

Support the Orbiter 2015 environment: Native support. Rewrite staging and such to make use of Orbiter 2015's new capabilities.

When we get closer to modeling an EVA situation, the SUIT ISOL valves in the LM need to have code written so that they cannot be switched to SUIT DISC if the suit pressure switch detects suit circuit pressure and the suit flow control breaker is closed.

It seems there are bugs in the LM power umbilical that are preventing the CSM from powering the LM during TLC. Possibly related, switching to the LM after being on CSM power and turning it back off, you cannot switch the batteries without a save and reload. Before any release that uses the LM, this needs to be addressed.

The event timer in the LM starts disabled by default.
EVENTTIMER_START ENABLED 0
The quick fix we have been doing is simply changing that back to "1" in the scenario file and everything works, but perhaps that enabled line doesn't need to be there? What would be the purpose of disabling the event timers in the first place?

In any case, can we look into this and see what is causing it to start disabled.

The LM keyboard controls for the DSKY don't match the CSM's. RSET (Shift + Pg Up) and KEY REL (Shift + Home) won't work completly, Shift + Decimal isn't CLR, but PRO (which should be Shift + End) -quite a gotcha if you want to make your first DSKY entry in the LM ("Okay, +38600, no, +35600. CLR...hey, I didn't want to proceed!").

The altimeter currently uses the altitude function of the Orbiter API. This function uses the main gravity source of the vessel, so that the altimeter will also show altitudes in low lunar orbit. This should be prevented by measuring altitude indirectly as a pressure altitude.

MCC should support generating PADs/uplinks for all major maneuvers in the Apollo 9 and 10 missions.

Certain systems are not wired up correctly, do not draw power yet or behave incorrectly on power transients.
Wire systems to proper breakers, draw the correct amount of power and properly simulate the events of a power transient.

Hi all,

when I do a lunar landing with the current version, the Contact Light comes up only when the footpads are touching the lunar surface. But it supposed to light up a few seconds earlier when only the probes have contacted with the ground. I've tried to figure out how this contact thing is handled and I've seen that the contact signal is practically based on the touchdown points specified in the function SetLmVesselHoverStage and these td points are only defined for the level of the footpads or above (there is some obscure code with other td points which refers to the CollisionSDK however I see no sign that these are ever taken into account during the creation of the contact signal). So first of all I simply added three new td points corresponding to the ends of the probes. To avoid the funny situation when the LM standing on the tip of the probes I reduced the stiffness and damping by a factor of 100 for these three new probes. Additionally I changed the number and the arrangement of the original td points to model more accurately the real layout of the footpads. Surprisingly this gives a much simpler set of touchdown points as the footpads are simply the four corners of a square rotated by 45 degrees. I tested my changes and now I can do the same free-fall touchdowns as you can see on the real Apollo videos. Also the LM sits firmly on it's footpads after touching down even on slopy terrain. I attached my version of lemmesh.cpp. You may incorporate the changes into the main branch if you are happy with these corrections.

Cheers

lemmesh.zip

Support the Orbiter 2015 environment - Basic operation. Operate as in 2010, no new feature usage except where necessary.

MCC phraseology should be able to be translated into non-English languages, ideally loaded from a resource file instead of compiled into the software so it can be modified by the user.

Hi folks,

I was experimenting with the cursor-spiral technique during P52, and I found it's accuracy is even worse than coarse alignment methods (in some cases I got for V06N05 a value more than +005.00, which is definitely unacceptable). I found out that my cursor measurements are quite good but the spiral ones are usually off up to a few degrees. I investigated the problem and discovered two sources of the inaccuracy:

1. This applies only on my machine (or on my fairly old monitor), because I cannot use orbitersim with more than 1024p vertical resolution. The problem is, that the AOT reticle needs 1050 pixels, so it will not fit into my 1024p screen. However the preset 60 degrees FOV is the screen's FOV and not the reticle's as it should be! So on my monitor the AOT FOV appears with a little bit more than 60 degrees which certainly explains some of the error in my spiral measurements. I changed the line in lemvc.cpp from
   oapiCameraSetAperture(RAD * 30.0);
   which simply set screen FOV to 60 to
   DWORD w, h;
   oapiGetViewportSize(&w, &h);
   oapiCameraSetAperture(atan(tan(RAD * 30.0) * h/1050.0));
   which will adapt the screen aperture in a way that it will align 1050 pixels to 60 degrees of FOV.
2. Although the change described above improved the accuracy (V06N05 was scattering around +000.70) still i wasn't satisfied with it. I understood that in calculations the LGC using the spiral's distance from the center as an angular value. For example if you rotate the reticle with 270 degrees after cursor measurement of a star to align the spiral on it, that means you see the star 3/4 way of the center or - more preciselly - the angle between the viewing direction and the star is 0.75 * 30=22.5 degrees. However the Orbitersim - as most of the 3d games - uses some sort of planar projection so there is no simple linear correspondence between pixel distance and angular distance as it is assumed in the current code for drawing the spiral. I derived the exact the formula for that (some trigonometry helps here) and I changed the way of calculation of the spiral's radial coordinate in lempanel.cpp from
   b = - RETICLE_RADIUS / (2*PI);
   r = b * theta;
   to the corrected version
   b = -RETICLE_RADIUS / tan(2 * PI *30/ 360);
   r = b * tan(theta * 30/360);
   That is the reason behind that I used that atan-tan formula in oapiCameraSetAperture instead of simply calculating 30 * h/1050 for desired FOV.
   There is a significant difference between the original (red) and corrected (green) spiral as you can see on screenshot below:
   

With these changes I was able to go down to +000.03 in star angle difference which is still not the "all balls" result I can sometimes achieve with the sextant and the CMC but I think I will not miss the Moon with this alignment if I attempt a landing :)

I attached the codes which contains my adjustments to the 22nd April version.
aot_spiral_corrected.zip

The roll indication can be wrong under certain circumstances. Scrolling down from 1° to 359° the indication doesn't go from 0 to 359 in all digits. The middle digit shows a 6 instead of a 0, as if it wants to display 360° instead of 0°.

I came to inform that I detected a bug in the Apollo project. In the Apollo 8 mission a checklist failure occurs in GET + 1h35. The maneuver pad does not appear in this GET, nor do we have information about the TLI later. This is happening in the last version (1263) for the 2016 orbiter. I also remember that in about 3 months this did not happen in previous versions.

MCC should use proper phraseology when communicating with the user. MCC interaction should be improved to more closely approximate actual usage.

I have a problem with Apollo 8 again (1264), but I'm not sure if it's really a problem. I assume from the checklist that it is normal for MCC burn to be scrubbed. But can it happen to more than one MCC burning? In my case both burns MCC1 and MCC2 are being scrubbed. Is this normal? Could it be a bug or will my trajectory do not need these two burns?

Thank you

Orbiter crashes when trying to update REFSMMAT on PAMFD.

Currently the padloads for the TVC DAP are sufficiently configured for maneuvers with the CSM. During SPS powered maneuvers with the docked CSM/LM the TVC DAP does not steer the spacecraft and maneuvers can only be done with the SCS. Correctly configured padloads will be needed for all missions involving the LM (Apollo 9 and later).

LM systems implementation for Apollo 9/10 features. Hardware used or tested in Apollo 9/10 should be able to perform the functions tested during those missions.

The procedure to zero the ICDU counters (Verb 40 in the AGC) also sets the IMU gimbal angles to zero and changes the attitude reference. This is not the intended behavior of the CDUs. In NASSP the CDU counters are not separately simulated at the moment, so the IMU gimbal angles and CDU "angles" are always identical.

A proper implementation would separate the digital counters and analog IMU readings. The method "DoZeroIMUCDUs()" in the IMU class is also often used, when a coarse alignment to zero is intended. This has to be changed as well.

When trying to dump the waste water the drains appear to be offset in front of the CSM when looking out the rendezvous window. See attached picture below.

According to MASTER ALARM TONE HEADSET CONTROL S/1-9 the master alarm can be inhibited by setting the power switches on panels 9, 10 and 6 from Audio/Tone to Audio.

After these actions have been taken the Master Alarm still triggers an audible warning.

Reference:

An issue with the CSM optics subsystem causes a CTD, usually during the sextant calibration for Cislunar Navigation (P23). I have tracked down the problem to part of the code that controls manual movements of the optics, first described here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2725.msg23578#msg23578

The simulation becomes stuck in this while loop in CSMComputer.cpp:

while(fabs(fabs(OpticsShaft)-fabs(ShaftMoved)) >= OCDU_SHAFT_STEP) {
sat->agc.vagc.Erasable[0][RegOPTX]++;
sat->agc.vagc.Erasable[0][RegOPTX] &= 077777;
ShaftMoved += OCDU_SHAFT_STEP;
}

The simulation was manually paused in debug mode and the relevant variables had these values at the time:

OpticsShaft = -0.00010406345
ShaftMoved = 391501.66411046032

The issue is difficult to reproduce, but it happens often enough to warrant further investigation.

Due to the terrain introduced in Orbiter 2016, the launchpads used in NASSP (mainly LC-39 and LC-34) are not 100% flat. This has a bad effect on the prelaunch alignment of the IMU in the Instrument Unit. While launches from LC-39A only get a slightly higher orbital insertion error due to this, the misalignment on LC-34 is much more severe and effectively break Apollo 7 launches at the moment. To fix this issue the elevation maps of Orbiter 2016 have to be edited.

Whilst doing the Apollo 7 mission I noticed that the Separation and P52 were swapped around in the flightplan. Attached is the correct version (In xlsx because Github doesn't allow xls).

Apollo 7 Flightplan vAGC.xlsx

In some cases after going from saturn takeover back to IU command of the SIVB, the S/C will maneuver to a weird attitude (yaw up to 45 degrees) and then slowly come back to 0 yaw afterwards. The issue happens when in saturn takeover, you manually maneuver to a yaw of 359 and less, then when you give control back to the IU, the LVDC seems to gets confused once it goes back up to 360, instead of counting up from 0 , it instead continues counting beyond 360, and up to 400.

The ECA CONT breakers only need to be closed to turn off the battery feeds. In our simulation, they are needed to switch on or off any batteries and this is not the correct behavior.

The logic needs to be fixed so that batteries can be switched on without those breakers closed (most notably the asc batteries, since those cont breakers are usually open) but cannot be switched back off without the breakers closed.

The LVDC++ needs to be able to fly the TLI. This includes generating whatever MCC assistance is required.

The LM ascent stage has weird behavior when staging in two ways:

1. During lunar liftoff, once staging fires, the ascent stage is spawned lower than it should. It gets created inside the descent stage, and then floats up to its proper resting position, on top of the descent stage.

2. In LM+CSM docked configuration, if one is inside the LM and stages, the ascent stage is spawned "pushed" into the command module. The only way to fix it is to save and reload, which seems to reset to the correct docking port parameters.

There seems to be an issue with the LGC's computed position during a lunar landing. The error is apparent after landing when comparing the LGC's idea of the position with P68, with the actual position displayed on an MFD such as PAMFD. In my tests I have noticed that while the downrange (longitude) error is almost nil, 0.01 or less, the latitude error is higher, about 0.04 degrees north of actual on average and sometimes higher. In my tests I have found the cause of this is the landing radar velocity updates that start when slowing through 2000 fps as per the padload and if I lower that to a very low value such as 600 fps, the error is pretty much gone. Another side-effect of this issue is if you perform an abort late during the landing, the lunar insertion plane will be off by as much as 0.3 degrees and that means the RR is unable to find and lock-on to the CSM.

or is it strictly limited to the moon?

I know I would need to edit a few parameters like fuel level and whatnot... but in theory is the tech on board the LM/CSM enough to do a flight to mars or for example alpha centari?

Support for failures on predefined conditions (Apollo 13, etc) and "random" conditions (MTBF simulation)