Meadville Space Center
Welcome, Guest. Please login or register.
December 14, 2019, 05:29:19 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
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 7 Beta Testing Bugs
« previous next »
Pages: 1 ... 4 5 [6] 7 Print
Author Topic: Apollo 7 Beta Testing Bugs  (Read 11055 times)
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #75 on: January 09, 2017, 08:44:13 AM »

Hmm very weird indeed, I mean once it comes up with the TIG page, I can quickly key V25 and it stays but if I dont press anything it goes back to the maneuver 50 18.

Also continuing our discussion from what needs done thread...

The PRO in the Checklist MFD probably belonged to the marking sequence still. After you have accepted the last mark with a PRO you have to wait at least 15 seconds until it is processed. Then you press PRO on the F 51 to end the marking sequence. The display will then return to F 16 45. Then you have to shortly wait until another F 06 49 appears, which displays the DR and DV change of the complete marking sequence, I think. Here you have to press PRO again to return to F 16 45 again. After about 15 seconds the mark count will go up by one. Only now you can recycle with V32E or go to the final pass with another PRO.

What you might have done is press PRO too quickly after you returned to the F 16 45 for the first time. Maybe the AGC took longer to process the marks and the Checklist MFD already told you to press PRO. Also note that the DR DV display prevents you from PROing for 2 seconds after it appears.

Might not hurt to clarify this in the checklist MFD because this is very easy to botch using checklist MFD and my A8 CMP checklist isn't clear on this either.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #76 on: January 09, 2017, 08:52:35 AM »

Maybe the start of P34 steals some cycles from P20 and when it's up and running, P20 catches up with the computation lag and throws out a new attitude which is too far off. I wouldn't bother too much about that.
The strange thing about the rendezvous is that I've flown it numerous times myself and never experienced it. Okay, P35 wasn't sharp as a knife, but this...whow! Shocked Guess the only way to find out is to move back in time scn by scn, fast forwarding each to rendezvous and see what happens. At one point it will work again and one of the procedures after that time has to be the guilty part.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #77 on: January 09, 2017, 08:53:30 AM »

Hmm very weird indeed, I mean once it comes up with the TIG page, I can quickly key V25 and it stays but if I dont press anything it goes back to the maneuver 50 18.

Just press ENTR on the F 50 18 if it pops up in P34, it's the same thing as before. It's already in the correct attitude, so it shouldn't appear again.

Quote
Might not hurt to clarify this in the checklist MFD because this is very easy to botch using checklist MFD and my A8 CMP checklist isn't clear on this either.

Before I can fix the Checklist MFD file I first have to find out what needs to be fixed. Once I have figured out what goes wrong I'll of course do the changes.

Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #78 on: January 09, 2017, 09:23:25 AM »

Oh I know, I just meant maybe inserting the part about waiting for the 06 49 to appear before proceeding after the marking sequence.

And now I am doing my last pass through P34 and I am getting constant 611 program alarms Sad
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #79 on: January 09, 2017, 09:27:53 AM »

Can you give me your scenario where that happens and maybe also a scenario just after NSR, so I can see if it has the same behavior as my scenario with the DR/DV?
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #80 on: January 09, 2017, 09:30:36 AM »

Sure, one is right before the RDV procedure starts (28h) and the other is the last pass through P34 where I cannot get past the 611 codes.

* Apollo 7 Rendezvous.scn (129.26 KB - downloaded 61 times.)
* Apollo 7 Rendezvous 0001.scn (134.08 KB - downloaded 60 times.)
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #81 on: January 09, 2017, 10:00:43 AM »

A V82 reveals that especially the periapsis of the S-IVB state vector is a few nautical miles off. So that might cause the 611. The state vector was made worse during the marking sequences I guess. But that isn't far off from what happened to me.

I also just tried the scenario at 28h GET with Colossus249. It seems to me that scenario flown with Colossus237 can be used in Colossus249 without too many problems, but the other way around it usually gives program alarms and P00DOOHs. Anyway, the F 50 18 in P34 does not happen with Colossus249. This is probably not really a problem though. P34 sets a few flags at the beginning and maybe P20 just reacts differently to that in C237.

I will also test the rest of the rendezvous. If I have a successful rendezvous, then it might be that there is an issue in Colossus237. After all it never actually performed a rendezvous and none of the planned alternative missions would have been a rendezvous. The optics zeroing after each marking sequence might also make a difference. If it turns out to be a Colossus237 problem then we have to find the procedure we are missing. I did a "successful" rendezvous with C237, but I also had the vAGC clock issue with the clock being a few seconds off and I blamed all rendezvous problems on that. The clock issue has been fixed for a while of course, so that's not the problem.
Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #82 on: January 09, 2017, 10:19:55 AM »

Just another wild idea: All the work that was done on the SCT/SXT recently for P23, could some of the changes there that made P23 marking better, may have affected the rendezvous marking?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #83 on: January 09, 2017, 10:41:25 AM »

Yeah, that's among the things I have already tried and reversed those changes for testing. Sometimes Noun 91 (the OCDU angles) doesn't exactly display the correct sextant angles, but that was already the case before. If anything the intermediate changes I had done to implement the resolved mode would have been more problematic. Now the CSM manual optics code is much better organized and I don't see a way where there could be a problem that hadn't existed for years.

I am half way through the P34 phase with the previously problematic scenario but using Colossus 249. I am able to get the W-Matrix converged to +00000 and +00002, which is what I usual get when the CSM state vector is good after NSR. So it seems to me there is something different here in C237.

EDIT: Welp, and then I get terrible results after the V93E during the last marking sequence. The DV is increasing from +00000 (the same all zeros I had previously) to +00034 to +00064 to +00105 or something like that. All very good marks. So still a W-Matrix issue. So annoying.
« Last Edit: January 09, 2017, 11:13:06 AM by indy91 » Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #84 on: January 09, 2017, 01:15:31 PM »

Wait, just to make things clear: the 'old and good' scenario runs Colossus 249, the 'new and bad' one 237?
Quote
Welp, and then I get terrible results after the V93E during the last marking sequence.
..and without the V93? I always use V93 once in the very beginning and never again afterwards.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #85 on: January 09, 2017, 01:39:53 PM »

Wait, just to make things clear: the 'old and good' scenario runs Colossus 249, the 'new and bad' one 237?

No, both were flown with C237. What I have tested now was the "new and bad" scenario with C249.

Quote
..and without the V93? I always use V93 once in the very beginning and never again afterwards.

Without V93 the W-Matrix will probably stay on very low values. All the V93 should do is set the W-Matrix flags to zero so that during the next measurement incorporation the W-Matrix gets reinitialized. Looking at the source code C237 only seem to reset the rendezvous flag, C249 resets some more.

The rendezvous values for the reinitialization, WRENDPOS and WRENDVEL, were changed to 1000 ft and 1 ft/s before the last marking sequence according to the Apollo 7 Rendezvous Procedures. And then after the third mark V93 is done, which was V86 in the Apollo 7 AGC version. The comment in the source code even still calls it V86. But after the V93 the first DR/DV was all zeros again and then it just got worse and worse. It almost seems like the W-Matrix is initialized with 0s, but I have checked the WRENDPOS and WRENDVEL EMEMs, they are never changed from the padloaded value except when you manually change them with V67 or directly as an erasable memory change.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #86 on: January 09, 2017, 02:00:01 PM »

So C237 has proven that it can perform a good rendezvous. Good, then we're back to procedures.
Quote
The rendezvous values for the reinitialization, WRENDPOS and WRENDVEL, were changed to 1000 ft and 1 ft/s before the last marking sequence
That's something that jumped into my eye: according to GSOP and the CMP checklist, R1 of N99 is in hundredths of NM, not in feet. The w-matrix might take longer to settle down when you load it with some high value...
« Last Edit: January 09, 2017, 02:02:40 PM by meik84 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #87 on: January 09, 2017, 02:16:44 PM »

So C237 has proven that it can perform a good rendezvous. Good, then we're back to procedures.

Kinda. As explained above I still had a vAGC clock issue and not really great results. But I didn't have the weird "Noun 49 all zeros and then really bad". And I got to the S-IVB, just with a larger DV than usual. That's much better than the 611 alarms (if that is a related issue) or 50 ft/s for MCC1 I got last time.

Quote
That's something that jumped into my eye: according to GSOP and the CMP checklist, R1 of N99 is in hundredths of NM, not in feet. The w-matrix might take longer to settle down when you load it with some high value...

I didn't change the values this time. Reinitializing to the padloaded values also causes the problem. The N99 was changed from NM to feet after C249 anyway.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #88 on: January 09, 2017, 04:36:20 PM »

Okay, I think I got it: there seems to be a documentation error and/or a different EMEM scaling. I initialized my w-matrix with
N99
R1 +01000 ('1000 ft')
R2 +00010 (1.0 fps)
R3 +00001
This brings good dV/dR, a TPI TIG of about 20s different then the pad and about 2 fps more dV. P35 works with that, too. I was able to make rendezvous with that. P35 isn't very sharp, though; I had to give him about 13 fps in -Z during manual TPF, i.e. it seemed like I was 'aiming too high'. Nothing unusual, I had that problem with all rendezvous before. No idea why it happens, but as long as I can catch it manually I don't care that much...
« Last Edit: January 09, 2017, 04:38:07 PM by meik84 » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #89 on: January 10, 2017, 08:56:40 AM »

So if we reinitialize with those values things should fall into place?  Not just using a V93 by itself?
Logged
Pages: 1 ... 4 5 [6] 7 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!