Meadville Space Center
Welcome, Guest. Please login or register.
December 12, 2019, 05:50:43 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP News & Discussion
| | |-+  Support & Bugs (Moderators: movieman, Tschachim, Swatch, lassombra)
| | | |-+  Apollo 8 Beta Testing Bugs
« previous next »
Pages: 1 [2] 3 4 ... 15 Print
Author Topic: Apollo 8 Beta Testing Bugs  (Read 17346 times)
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #15 on: November 26, 2016, 09:56:29 AM »

I think we should create an issue on Github for this and forget about until we work on NASSP 8.0.  Very Happy

Agreed, I guess I will leave the 5.7 psi thing in the checklist for now.  Back to checking 8 for fixable bugs for the 7.0 release!

You can get it at: http://www.spacecraft.it/ Just register, write a nice email and get the AOH Volume 2 and a few other documents. They went through the effort to scan these documents and these are large files, so I guess they want to limit their bandwidth costs.

So I started typing the email address, looks like I did register with then in 2011 Happy  Got the AOH!
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #16 on: November 26, 2016, 01:10:41 PM »

Thanks, indy. That'd also explain why there's no option to cross-check the landmark lat/lon/alt when I do landmark tracking. Not in the Colossus builds, I guess.  Yuck!
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #17 on: November 26, 2016, 03:19:22 PM »

The MCC now supports TLC aborts. The Abort Maneuver PADs were calculated already anyway, so I just wanted to implement them as aborts that are not caused by a loss of communications.

The MCC has a lot of Mission States, but now it also has major mission phases, which are: Earth Orbit, Translunar Coast, Lunar Orbit, Transearth Coast, Entry. Because this is a new variable you have to start a new mission to try the abort, or you could edit in the MissionPhase parameter to your old scenario.

To start the abort sequence, you have to request the abort in the CAPCOM menu, which was now added as a menu option there. After you have confirmed the abort, it will then check in which mission phase you are. Currently only the TLC aborts are implemented. The MCC will use the last abort maneuver, for which you got a Maneuver PAD. So from TLI to a few hours after TLI the TLI+4 abort will be used. After you have performed the abort maneuver, the MCC will check if there is enough time between the Direct Abort Maneuver (DAM) and Entry Interface (EI) for another course correction other then the nominal EI-2 hour MCC. If yes, and this should be the case for the TLI+4 abort, then it will add another MCC 5 hours after the DAM. This timing is consistent with the Loss-of-Comm procedures. After this additional course correction the nominal entry schedule will be used by the MCC. The uplink for this course correction also includes the desired Entry REFSMMAT.

All other mission phases are currently not supported and if you select an abort for these, then no additional MCC updates will happen. Adding support for an abort from Lunar Orbit is easy, it will just switch to the nominal TEC schedule after the early TEI. An abort from TEC would involve moving the landing site, which would only be done in a time critical abort. Flyby is also not yet supported.
Logged
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #18 on: November 26, 2016, 05:38:57 PM »

As far along as LOI-2 on Apollo 8. No problems to report so far. Would some tolerances for P23/P52 in the Checklist MFD be possible to help a user decide whether to accept or reject a state vector or alignment? Something like:

N05 < +00004 then PRO
N05 >= +00004 then reject
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #19 on: November 27, 2016, 09:19:52 AM »

As far along as LOI-2 on Apollo 8. No problems to report so far. Would some tolerances for P23/P52 in the Checklist MFD be possible to help a user decide whether to accept or reject a state vector or alignment? Something like:

N05 < +00004 then PRO
N05 >= +00004 then reject

It wouldn't hurt, though if someone is using the auto checklist they would have to issue the V32 and pause it to go back to the proper step unless we implement a FAIL option like @jalex has done for the P40/41 options.

EDIT:  So I was experimenting and added the FAIL condition to the P52 in the Apollo 7/8 checklist.  Once it is merged please give it a try make sure I didn't miss anything.  If everything works I can start doing it with the P23.
« Last Edit: November 27, 2016, 11:37:50 AM by rcflyinghokie » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #20 on: November 27, 2016, 12:12:28 PM »

I tested it and there is a problem with the sequence. After you complete the repeated marking sequence, it goes back to where you pressed fail in the original P52 checklist. So it wants you to do the gyro torquing etc. again. I guess you can solve this by removing all the checklist items after the accept/fail decision from the Bad Angle checklist.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #21 on: November 27, 2016, 12:21:18 PM »

I tested it and there is a problem with the sequence. After you complete the repeated marking sequence, it goes back to where you pressed fail in the original P52 checklist. So it wants you to do the gyro torquing etc. again. I guess you can solve this by removing all the checklist items after the accept/fail decision from the Bad Angle checklist.

Ah I did not catch this, I will post a fix shortly.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #22 on: November 28, 2016, 06:32:51 AM »

There is still a problem: https://github.com/dseagrav/NASSP/pull/32#issuecomment-263136429
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #23 on: November 28, 2016, 08:01:12 AM »


Done, forgot I added the P51 to Apollo 8
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #24 on: November 28, 2016, 09:36:33 AM »

I have added MCC Abort support for the flyby and PC+2 maneuvers and the early TEIs. It's not properly tested yet, but I will do that over the next few days. The only abort maneuvers that are now calculated by the RTCC but are not supported by the MCC yet are the TLI+90 minutes maneuver, the fast PC+2 (24 hours early return) and TEI-11 (one revolution later than planned). It's a little bit difficult to support these, because they are calculated "out of sequence". The TEI-11 Maneuver PAD for example is already given to the astronauts just after the final TEI-10 Maneuver PAD. And the times for TEI and EI are saved with each maneuver calculation and are important for the TEC sequence, so MCC support for TEI-11 would currently break the nominal return sequence. I have some ideas how to implement full support for abort maneuvers, that that would require the MCC to be reworked in some ways, which is not something I want to do so close to the release. So I think all I will do is test the changes I have done and then work on MCC abort after the release.
Logged
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #25 on: November 28, 2016, 10:49:04 PM »

Not sure if this is a bug or mismanagement of the AGC. Lost my IMU alignment and can't get it back. Here's a run down of what happened, if something doesn't make sense I can post a scenario.

I was running P22 psuedo landing site tracking on rev 5, just before the night pass (78:05 GET I believe). I took 5 marks per the flight plan

F 50 25 00016 PRO to
F 05 71 (landmark data) PRO to
F 06 49 (SV change) it was high so I keyed V32E to recycle

Got a program alarm W-Matrix Overflow, went to P00 and quicksaved. Later went to do a P52 and with optics in CMC the computer was not pointing the optics at anything in particular. Marked the stars in manual and got a very large error. I tried a sextant star check with one of the abort PADs, still not pointing at the correct star. So I tried doing an alignment with the set stars on the abort pad, and that didn't work either. Did I miss something here? Was I supposed to do something about that program alarm?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #26 on: November 29, 2016, 06:42:16 AM »

Got a program alarm W-Matrix Overflow, went to P00 and quicksaved.

I'd be interested in seeing this quicksave. I had W-Matrix overflow in the past, too. Each time your state vector is propagated in P00, the W-Matrix also gets modified. Basically, there is an uncertainty in the state vector integration routine and if you coast for a long time without a state vector update from the ground, the accuracy of the state vector is getting too high. The program alarm (421 I guess?) just tells you your state vector is not good enough, but that can usually be ignored. I think Apollo 9 or so also got this once.

Quote
Later went to do a P52 and with optics in CMC the computer was not pointing the optics at anything in particular. Marked the stars in manual and got a very large error. I tried a sextant star check with one of the abort PADs, still not pointing at the correct star. So I tried doing an alignment with the set stars on the abort pad, and that didn't work either. Did I miss something here? Was I supposed to do something about that program alarm?

I doubt the W-Matrix program alarm is related to the alignment problem. Maybe the optics weren't zeroed for the P52? In that case the CMC doesn't properly know where the optics are pointing. Did you maybe get another program alarm, 116 or 120?
Logged
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #27 on: November 29, 2016, 08:57:11 AM »

Optics were zeroed after the P22, just before the program alarm. No other alarms. This scenario is immediately after the P22.

* W-Matrix.scn (160.53 KB - downloaded 68 times.)
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #28 on: November 29, 2016, 09:44:37 AM »

Something weird is going on with the optics there. If you look at the OCDU angles (V16 N91), the angles are very different from the mechanical readouts for shaft and trunnion and zeroing doesn't work either. No idea yet why that happens.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #29 on: November 29, 2016, 10:57:43 AM »

Something weird is going on with the optics there. If you look at the OCDU angles (V16 N91), the angles are very different from the mechanical readouts for shaft and trunnion and zeroing doesn't work either. No idea yet why that happens.

Even zeroing with a V41 N91 does not work nor resetting the optics.  I wonder if the optics positioning in the P22 screwed this up?

EDIT:  I ran a V36 and reset the REFSMMAT flag and uploaded the current REFSMMAT and the optics zero again.
« Last Edit: November 29, 2016, 11:06:09 AM by rcflyinghokie » Logged
Pages: 1 [2] 3 4 ... 15 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!