Meadville Space Center

Project Apollo - NASSP => Support & Bugs => Topic started by: rcflyinghokie on November 05, 2016, 08:01:42 AM



Title: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 05, 2016, 08:01:42 AM
I guess I will start it off with what I think is one little audio bug, the audio clip during pre launch of Jack King saying the "crew is at the 320 foot level" etc should only be used for a Saturn V flight, as the Saturn 1B was of course not even 200 feet tall :)


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 05, 2016, 10:54:40 AM
Done. This is a non mission specific sound, so I had to add an if condition, so that this is only played for Saturn V vehicles. I don't think we have a Saturn IB equivalent.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 06, 2016, 09:16:15 AM
Another one for you, the LV IU/CMC switch no longer gives control to the CMC for maneuvering the SIVB.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 06, 2016, 01:20:16 PM
Another one for you, the LV IU/CMC switch no longer gives control to the CMC for maneuvering the SIVB.

Looks to me like it's an DAP quirk, maybe only happening in Colossus237. Just do a V48 again with a V46 at the end and it suddenly works. No idea why that is required. If you do a V37E00E after the V46E then the takeover doesn't work anymore. I have the feeling I have read something about this in a transcript somewhere, but I don't know which mission...

EDIT: It doesn't seem to happen for Apollo 9 with Colossus249, although the Saturn V LVDC takeover works exactly the same. In Colossus237, the "EnableSIVBTakeover" bit in output channel 12 must have been reset by going to P00. Here the description of the bit for the downlink in GSOP section 2:

Quote
S4B Takeover Enable. Set to 1 following a V46E with bits 14-13 of DAPDATR = 1 (for Saturn attitude control using RHC). Can be reset to 0 by V37E00E, or a restart (since "Saturn DAP" is not restart protected) of bits 15-14 of Flagword 6.

There is no extra version of this page in the GSOP for Colossus IA, so it shouldn't really work much differently in C249. I'll have to look into the C237 and C249 code to see where the difference is.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 09, 2016, 08:08:30 AM
I cannot figure out what is causing this, but I am getting an OPR ERR light whenever I load V49 in the A7 mission.  It doesn't effect the V49 itself but should not be lighting up when I call a V49.

EDIT:  Sidenote, I noticed the checklist MFD after the SIVB sep does not open the seq events logic cb's back up, I believe it is supposed to after securing from a seq event/pyro activity.  Additionally, I do not know if it effects anything but shouldn't the dV switch be on CM this mission and in A8 from launch?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 09, 2016, 09:26:14 AM
I cannot figure out what is causing this, but I am getting an OPR ERR light whenever I load V49 in the A7 mission.  It doesn't effect the V49 itself but should not be lighting up when I call a V49.

It's a Colossus 237 bug and very much expected. It's even in the Apollo 8 CMP Checklist, see the discussion here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.msg24545#msg24545

Quote
EDIT:  Sidenote, I noticed the checklist MFD after the SIVB sep does not open the seq events logic cb's back up, I believe it is supposed to after securing from a seq event/pyro activity. 

I'll check it, I probably forgot to add this to the Checklist.

Quote
Additionally, I do not know if it effects anything but shouldn't the dV switch be on CM this mission and in A8 from launch?

For Apollo 7 yes. The AOH section 2 actually states that for a CSM with full propellant tanks the switch should be set to CSM/LM during launch for the suborbital aborts. This affects the TVC gains for a Mode III abort, which makes the CSM more stable (but also less precise). The switch is currently not functional in NASSP, I have found two documents that have the exact values of these gains, but the behavior which these gains is pretty bad, so I'll have to do more research and testing.

I'll go through the Apollo 7 Checklist and look if the switch is set to the wrong setting somewhere.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 10, 2016, 01:32:08 PM
I have been getting a CTD every time it generates the thread for the 22h25m maneuver pad.  Here is the recent save before it.  But I even started a new mission and am having the same CTD location.  The error is below.

The thread 0x2808 has exited with code 0 (0x0).
Unhandled exception at 0x100ED83C (Saturn1b.dll) in orbiter.exe: 0xC0000005: Access violation writing location 0x67698844.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 10, 2016, 01:49:42 PM
Works fine for me with that scenario. Maybe it's a problem wtih debug mode again? Or have you been building the NASSP solution in Release mode? In that case I have no idea why it would work for me, but not for you...


Title: Re: Apollo 7 Beta Testing Bugs
Post by: dseagrav on November 10, 2016, 02:11:37 PM
The stack backtrace would be helpful if you can get it


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 10, 2016, 02:32:46 PM
Works fine for me with that scenario. Maybe it's a problem wtih debug mode again? Or have you been building the NASSP solution in Release mode? In that case I have no idea why it would work for me, but not for you...

I have been building in Release mode.

The stack backtrace would be helpful if you can get it

How would I go about this?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 10, 2016, 03:42:40 PM
I mean, what else than a build problem can it be? I have no uncommited changes to the MCC and RTCC and your scenario is working fine for me, no problem with the NCC1 Maneuver PAD. Can you try and REbuild the solution?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: dseagrav on November 10, 2016, 04:53:27 PM
How would I go about this?

I don't remember off the top of my head. If anywhere it will be around the same place you got the message you posted earlier. There will be something that says "stack trace" or "call trace" or something like that.

I mean, what else than a build problem can it be?

Any of a grocery list of things, most likely of which is an uninitialized variable. On your computer it just happens to work out but in his case there's a difference somewhere that breaks things.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 10, 2016, 09:53:06 PM
I mean, what else than a build problem can it be? I have no uncommited changes to the MCC and RTCC and your scenario is working fine for me, no problem with the NCC1 Maneuver PAD. Can you try and REbuild the solution?

Just did a rebuild and everything worked.  The last build I did was all successful too so I haven't a clue what happened.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 11, 2016, 06:54:53 AM
Still might be uninitialized variables. I actually found one already relevant for the NCC1 maneuver, but that particular variable can be in any state and it wouldn't cause harm. I'll search a little bit more, but of course it just might have been a build problem.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 11, 2016, 07:46:22 AM
Still might be uninitialized variables. I actually found one already relevant for the NCC1 maneuver, but that particular variable can be in any state and it wouldn't cause harm. I'll search a little bit more, but of course it just might have been a build problem.

I just loaded it up this morning for fun and it gave me the same ctd even though it worked yesterday, so hunting for an issue is probably still prudent.

Throws an exception at this line

Code:
oapiAnnotationSetText(NHmessages,msgOutputBuf); // update the annotation

It also happens in the save file after the thread was generated when I try to repeat uplink.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 11, 2016, 08:12:50 AM
I can cause a CTD on this line by generating lots of MCC calculations, which are then displaying too many messages. I haven't ever really looked at this part of the MCC, but it seems to me there is a limited number of messages that can be displayed and if more messages are written than that to the character array, a CTD happens. This doesn't involve the PAD, just the messages displayed to the top and right of the PADs.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 12, 2016, 09:27:08 AM
So its weird, I can get a CTD on a thread update, but I can reload my quicksave prior and no CTD.  I cannot seem to get anything consistent.

But some other notes on 7 (which probably trickle over to any checklist MFD)

-EDS breakers not opened after SIVB sep
-SIVB LM SEP breakers are closed, I know these arent even used but should these be opened before launch for A7 or at the very least opened after SIVB SEP?
-SPS P&Y BAT breakers only two (BAT A) are opened after the burn instead of all four.
- Was the SCS TVC kept on RATE versus AUTO for A7 SPS burns?  The checklist keeps them on rate before the TVC tests but never moves them to auto.


I am only at 27 hours but I will keep an eye out for more :)


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 12, 2016, 12:11:48 PM
So its weird, I can get a CTD on a thread update, but I can reload my quicksave prior and no CTD.  I cannot seem to get anything consistent.

Maybe it is the too many messages thing I mentioned above. Dseagrav has to take a look at that, I don't really know how it works...

Quote
-EDS breakers not opened after SIVB sep

Yes, those should probably be opened.

Quote
-SIVB LM SEP breakers are closed, I know these arent even used but should these be opened before launch for A7 or at the very least opened after SIVB SEP?

Yes, they should be open after S-IVB sep. If it isn't implemented, I will look into doing that. The breakers were closed for launch.

Quote
-SPS P&Y BAT breakers only two (BAT A) are opened after the burn instead of all four.

Nominal P40 checklist has only two opened after the burn. You will open all four only after the last SPS maneuver (deorbit).

Quote
- Was the SCS TVC kept on RATE versus AUTO for A7 SPS burns?  The checklist keeps them on rate before the TVC tests but never moves them to auto.

For Apollo 7 it depends. Usually it would be in RATE during a AGC controlled burn. If you really need to take over control with the SCS you might have a high attitude rate and attitude excursion, you probably want to first bring the spacecraft under control before giving the SCS auto control. If you notice something is wrong with the CMC BEFORE the burn has begun, then the P40 checklist sets it to auto.

There are two nominally SCS controlled burns during Apollo 7 and they have a separate checklist in the MFD with the switch to Auto. There is also a MTVC takeover planned, where it is set to RATE CMD and you will have to control the TVC manually.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 14, 2016, 07:43:00 AM
RCS Logic, SIVB/LM Sep and EDS circuit breakers are now opened in the Checklist MFD after separation. The SIVB/LM circuit breakers were already properly implemented before. I have also commited a few RTCC fixes, although these issues can't have caused the CTDs rcflyinghokie experienced.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 15, 2016, 09:27:50 PM
RCS Logic, SIVB/LM Sep and EDS circuit breakers are now opened in the Checklist MFD after separation. The SIVB/LM circuit breakers were already properly implemented before. I have also commited a few RTCC fixes, although these issues can't have caused the CTDs rcflyinghokie experienced.

I am still getting them in later MCC updates post rendezvous.  Is there anything I can do to try to pinpoint these?

Tried re-saving rebuilding everything cannot get past the 44h SV update.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: dseagrav on November 16, 2016, 04:46:25 AM
Did the size of something change in a way that makes the malloc (or whatever) come up short, or is it writing past the end of the buffer?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 16, 2016, 06:53:46 AM
I am still getting them in later MCC updates post rendezvous.  Is there anything I can do to try to pinpoint these?

Tried re-saving rebuilding everything cannot get past the 44h SV update.

I am getting the CTD at 44 hours, too, with your scenario. That one might be a PAD saving/loading issue.

EDIT: The exception is in the line

Code:
oapiAnnotationSetText(NHpad, buffer);

while writing the the buffer containing the Nav Check PAD in the Orbiter annotation.

EDIT2: Ok, I am pretty convinced now that all the new MCC problems are caused by the recently implemented PAD saving/loading. I'll try to find the problem.

EDIT3: Looks like it might only be the loading of the uplink string that is causing the problems. That would be much easier to solve than the PADs.

EDIT4: That uplink shouldn't be saved anyway, it doesn't belong to the saved Block Data.

EDIT5: It goes a little bit deeper than that. I am working on it but it will take time.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 17, 2016, 09:45:41 AM
Ok, this is the problem. When I decided how to save PAD data in a scenario I had two option: save the string containg the PAD or save all the variables separately. The first option would have required the MCC to be reworked quite a bit, so I chose the second option. But I accidentally left some code in the MCC for the first option, namely a PADbuffer:

Code:
//Save PAD string
sprintf(padBuffer, buffer);

This had severe side effects, for some reason I don't fully understand. Probably the nature of the PAD string with several lines of characters. Here an excerpt of the MCC class declaration:

Code:
char padBuffer[512];
 
// UPLINK DATA
int uplink_size; // Size of uplink buffer
unsigned char uplink_data[1024]; // Uplink buffer

// CAPCOM INTERFACE
NOTEHANDLE NHmenu; // Menu notification handle
NOTEHANDLE NHmessages; // Message notification handle
NOTEHANDLE NHpad; // PAD display handle
int menuState; // Menu state

The string written to padBuffer also overwrote a few following variables, mostly the uplink stuff, but it also could break the NOTEHANDLEs I think.

I guess I have some reading about sprintf to do, but the fix is easy, remove the obsolete code. In my quest for finding this issue I also reworked some other parts of the MCC, so as always there is potential for new bugs.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 17, 2016, 12:29:35 PM
I guess I have some reading about sprintf to do, but the fix is easy, remove the obsolete code. In my quest for finding this issue I also reworked some other parts of the MCC, so as always there is potential for new bugs.

Should this have fixed the CTD in the scn file I posted?  Because I am still getting it.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 17, 2016, 12:39:44 PM
Should this have fixed the CTD in the scn file I posted?  Because I am still getting it.

I forgot to test it with the original scenario you posted. You have to delete the MCC_upString line in the scenario. It shouldn't have been saved and it doesn't belong to the saved Block Data.

That said, I think there still is a bug similar to the one I explained above. Expect more bug fixes soon...

EDIT: Ok, the additional problem is the variable uplink_size. If an uplink string isn't actually uplinked, then this doesn't get reset to 0 again. The next uplink string simply gets added to this variable and at the second or third uplink the size will exceed 1024, which is the maximum. And exceeding the maximum again overwrites the next variables in the MCC class, which are the NOTEHANDLEs for PADs, messages etc. This is what happens when an uplink saved in a scenario doesn't get uplinked and you simply proceed to the next RTCC calculation. That's also what causes CTDs when you use the debug menu to skip several mission states without uplinking anything.

I think it is safe to reset the uplink size to 0 when a new RTCC calculation is triggered. If you proceed to the next mission state as usual, then the old uplink string isn't relevant anymore. And if you repeat a calculation, then a new uplink gets calculated anyway. With this change you can now also use the debug menu to quickly go through mission states with uplinks, without CTDs.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: dseagrav on November 17, 2016, 02:54:25 PM
IIRC that was used to keep track of where we were in sending bytes to the computer, which lets you batch uplinks together and transmit them in one go. (This was done in real life).
It should be reset to zero when the last byte is given to the computer. Resetting it with new states just means the uplinks never happen or get cut off in the middle.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 17, 2016, 03:25:58 PM
The uplinks are already batched together in our RTCC. Some of the uplinks are very long, so if you collect strings in the MCC that haven't been uplinked yet, it quickly violates the 1024 character limit. I tried to increase this limit, but it crashed again and I think 1024 is also used somewhere in the PCM. Even the longest single uplinks (e.g. 2 state vectors + REFSMMAT) don't violate the 1024 characters, but if you have 2x2 state vectors then it becomes a problem.

I haven't changed that "uplink_size" gets reset to zero after the last byte is given to the computer. It just also gets reset now at the beginning of a new state.

Do you have a better idea where to reset it to zero if not at the beginning of a new state? The variable "upString" is also reset there. And I don't think that RTCC and MCC both need to have the capability to batch uplinks. If the MCC doesn't do it, then you could skip uplinks. Before my commit today, you were forced to do an uplink or else you get the CTD. I'd rather have the ability to use the debug menu to quickly advance through mission states.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: dseagrav on November 17, 2016, 03:56:35 PM
It's fine as long as at least one or the other can do it. If RTCC already does it better then there's no need for MCC to do it. After we move to 2016 there will be a lot of chances to clean up and we can drop it as unneeded extra complexity then.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 20, 2016, 09:33:35 AM
This is not really a bug but perhaps a lack of information issue (or just my ignorance since this is my first complete run through Apollo 7  :oops:.  For the P22 sets around 122 hours, the checklist MFD says use previously computed landmark coordinates.  Where does the user get this information for the P22?  And are these landmarks modeled marked in orbiter right now?  

EDIT:  Too add, where does the user get the P23 star information to use right after the P22's?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 20, 2016, 10:30:52 AM
The word flight plan has the P23 stars and the update forms document has the P22 landmarks, already converted to the coordinates required for the AGC Earth ellipsoid calculations. These landmarks are not the ones used during the historical Apollo 7 flight, because we don't have a source with a complete lists of the Apollo landmarks. I might be able to come up with a better list of landmarks for P22, but for now the ones in the update forms document should be good enough. Just like star markings you can display lots of landmarks on the Earth. I think these already come with Orbiter and not NASSP.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 20, 2016, 10:49:38 AM
Ah perfect, I didn't think of looking at the update forms for the P22 info.  And I am blind because I had the FP doc open and totally missed the P23 stars.  Guess I need more coffee :P

Also for the P23, are you using direct or resolved coupling?  And is the sxt slaved to the sct?  The checklist MFD does not specify though I remember in 8 using resolved coupling and 0 degrees for the trunnion.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 20, 2016, 11:02:12 AM
Also for the P23, are you using direct or resolved coupling?

Direct usually. I don't think the checklists specify this for P23, but resolved mode tends to confuse me while pointing the optics at stars. Resolved mode is mostly useful for landmark tracking.

Quote
And is the sxt slaved to the sct? The checklist MFD does not specify though I remember in 8 using resolved coupling and 0 degrees for the trunnion.

Not sure what is the best technique, I think I usually have it set to "Slave to Sextant". But I am no P23 expert really.

Also, good luck with P23 during Apollo 7. Because the astronauts sure didn't have any success with it. According to the mission report they did start P23, but never did any marks. They couldn't properly see the horizon as a defined line so close to Earth, so they abandoned further P23 tests after their initial attempt.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 20, 2016, 11:26:06 AM
Also, good luck with P23 during Apollo 7. Because the astronauts sure didn't have any success with it. According to the mission report they did start P23, but never did any marks. They couldn't properly see the horizon as a defined line so close to Earth, so they abandoned further P23 tests after their initial attempt.

Thats the same issue I am having, glad it's not just me!


Title: Re: Apollo 7 Beta Testing Bugs
Post by: eddievhfan1984 on November 21, 2016, 03:29:56 PM
I've been trying P23 with Apollo 8, and even that's rather annoying. Slave to SXT makes the most sense to me when manually searching for the star, but keeping the SCT at 0 is helpful for maintaining horizon track. Though I'm not entirely sure why P23 doesn't orient the vehicle to line up the horizon tangentially with a shaft angle of 0. :P In addition, at relatively close range, including EPO, it's hard holding the horizon perfectly stable, anyways. I'd rather use P22 to navigate in that case, if I'm honest...


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 21, 2016, 03:40:13 PM
Though I'm not entirely sure why P23 doesn't orient the vehicle to line up the horizon tangentially with a shaft angle of 0. :P

Yeah, that would be nice. But the earlier versions of the CMC don't have the 3-axis pointing routines used by the LGC during e.g. ascent and descent. It was only added for Apollo 15 (Artemis), so in that AGC version P23 has the option to go to the tracking attitude with minimized propellant use (VECPOINT) or constrained attitude (3-axis). I haven't tried P23 in Artemis072, but I'm sure it is much more convenient.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 21, 2016, 04:21:28 PM
In the MCC updates, are there supposed to be sxt star check stars with shaft/trun angles generated as well in the PAD?  Every MCC I get on 7 has 0's for all of those values.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 21, 2016, 04:30:10 PM
In the MCC updates, are there supposed to be sxt star check stars with shaft/trun angles generated as well in the PAD?  Every MCC I get on 7 has 0's for all of those values.

Yes it should. Examples? I just tried to generate a Maneuver PAD for the NCC1 maneuver and it came up with a star ID. I think quite a few of the later maneuvers are in the heads-up attitude, so in that case no sextant stars are available because the Earth is in the way. That's why the RTCC MFD has an option to calculate the sextant star with a time relative to TIG, so that you can do the check early, even if the view is blocked at TIG. For the MCC I have implemented this whenever the flight plan has a specific time for the sextant star check. In the case of the NCC1 maneuver this is 30 minutes before the burn. At that time the view isn't blocked yet, but it will be later.

Are there Maneuver PADs that hava 0 as the star but not 0 as the angles?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 21, 2016, 04:34:33 PM
In the MCC updates, are there supposed to be sxt star check stars with shaft/trun angles generated as well in the PAD?  Every MCC I get on 7 has 0's for all of those values.

Yes it should. Examples? I just tried to generate a Maneuver PAD for the NCC1 maneuver and it came up with a star ID. I think quite a few of the later maneuvers are in the heads-up attitude, so in that case no sextant stars are available because the Earth is in the way. That's why the RTCC MFD has an option to calculate the sextant star with a time relative to TIG, so that you can do the check early, even if the view is blocked at TIG. For the MCC I have implemented this whenever the flight plan has a specific time for the sextant star check. In the case of the NCC1 maneuver this is 30 minutes before the burn. At that time the view isn't blocked yet, but it will be later.

Are there Maneuver PADs that hava 0 as the star but not 0 as the angles?

Thats what I was thinking but I was not sure, the head's up maneuver position answers my question.  Yes I get one for NCC1 but as you pointed out, the other SPS burns were I believe all heads up, thus the sextant is facing the wrong way.  My mistake!  :oops:

And no, I have not seen a case where there is 00 as a star and non zero angles, so looks like everything is working as intended.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: mikaelanderlund on November 22, 2016, 01:46:56 PM
Maybe a stupid question but do I need NASSP_V7.0-Beta 20150804 if I download V7.0 Beta-master-275? Or should I use both :?

/Mikael


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on November 22, 2016, 02:02:32 PM
Maybe a stupid question but do I need NASSP_V7.0-Beta 20150804 if I download V7.0 Beta-master-275? Or should I use both :?

/Mikael

This is a confusing leftover from the time when you had to download the modules separately. I guess that way you only had to download the new modules, if you wanted to keep up with the recent Beta developments, and not all the other data, too. Right now there is only really a difference between releases that have the source code and releases with completely prebuild modules. Both versions have all the other data, bitmaps, meshes etc.

So in short, all you have to download is this: https://github.com/dseagrav/NASSP/releases/download/NASSP-V7.0-Beta-master-275/NASSP-V7.0-Beta-master-275.zip And we should change the wiki to be less confusing.

EDIT: The most recent "Modules Pack" on Github is now linked on the Wiki, instead of the outdated build on Sourceforge.



Title: Re: Apollo 7 Beta Testing Bugs
Post by: mikaelanderlund on November 22, 2016, 02:42:32 PM
Thanks indy and I look forward to the big release. It will be a great day in the history NASSP!


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on November 22, 2016, 10:55:14 PM
Other than a few minor timing issues with the checklist MFD in auto, Apollo 7 went through beautifully.  Now to test 8 again :)


Title: Re: Apollo 7 Beta Testing Bugs
Post by: papymaj5 on December 01, 2016, 11:17:08 AM
Hello,

As a relatively inexperienced Apollo user, I have come across some issues and questions:

1. ORDEAL switch position check - ALT SET as desired, what would be a desired altitude?
2. CAPCOM Menu - What is it for and when I select voice check it does nothing.
3. Can you make the MFD's bigger? Hard to read the checklist in high resolution monitors.
4. Copy Maneuver PAD? How do you get the info from RTCC?
5. How do I enable the Saturn DAP?
6. With latest build CTD at +56Minutes - Right at State Vector Update. Loaded from a save, though from latest build. Shows Threaded Started At Top.

I have only gotten to post SIVb Sep before it got difficult.

Thanks, Jon


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 01, 2016, 11:42:12 AM
1. ORDEAL switch position check - ALT SET as desired, what would be a desired altitude?
At this point the ORDEAL is not being turned on, so you can leave the ALT SET in it's default position.  It will be set later when an average orbital altitude is computed.

2. CAPCOM Menu - What is it for and when I select voice check it does nothing.
If I am not mistaken this is not implemented yet, nothing to worry about.  I am sure Indy can give more details on this future implementation.

3. Can you make the MFD's bigger? Hard to read the checklist in high resolution monitors.
I do not know, I am sure there is a way, I will let someone with more knowledge in this area answer :P

4. Copy Maneuver PAD? How do you get the info from RTCC?
This is from the MCC not the RTCC MFD.  It's the yellow text that appears on the left.  Make sure you have "Auto PAD" enabled and "Hide/Show PAD" is not hiding it.

5. How do I enable the Saturn DAP?
The step following this text explains it, making sure your DAP (V48) has a 3 in the first digit of R1

6. With latest build CTD at +56Minutes - Right at State Vector Update. Loaded from a save, though from latest build. Shows Threaded Started At Top.
Since the new build I have not had an issue here, maybe post a quicksave .scn file before your CTD?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 01, 2016, 12:02:43 PM
2. CAPCOM Menu - What is it for and when I select voice check it does nothing.
If I am not mistaken this is not implemented yet, nothing to worry about.  I am sure Indy can give more details on this future implementation.

Yeah, I don't think the vocie check is doing anything. The rest of the CAPCOM menu is for interaction with the MCC.

There are currently two ways of flying the Apollo 7 and 8 missions: Let the MCC calculate everything for you (maneuvers, state vectors etc.) or use an MFD for it (the "new" RTCC MFD is a dedicated tool for this, but LTMFD and IFMD are also still working with NASSP). Using the MCC is very convenient, because you don't have to find out which orbital parameters you want to have after a maneuver etc. There are separate launch scenarios for MCC or without MCC.

Quote
3. Can you make the MFD's bigger? Hard to read the checklist in high resolution monitors.
I do not know, I am sure there is a way, I will let someone with more knowledge in this area answer :P

I think you can only do that with external MFDs. The size of the normal MFDs is hardcoded in NASSP.

Quote
4. Copy Maneuver PAD? How do you get the info from RTCC?
This is from the MCC not the RTCC MFD.  It's the yellow text that appears on the left.  Make sure you have "Auto PAD" enabled and "Hide/Show PAD" is not hiding it.

If you don't use the MCC, you can of course still calculate the Maneuver PAD with the RTCC MFD.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: papymaj5 on December 01, 2016, 05:17:33 PM
How do I "Hide/Show PAD"? I can't find a reference in the options or in one of the MFDs.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 01, 2016, 05:41:44 PM
How do I "Hide/Show PAD"? I can't find a reference in the options or in one of the MFDs.

Its one of the options in the MCC menu in the top left corner, the CAPCOM menu.  Also this will only be working from the start if you are flying the scn with MCC enabled.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: dseagrav on December 01, 2016, 08:37:51 PM
Voice check presently does nothing but test the screen IO. It's intended to be used as part of communications establishment later when AOS/LOS actually means something.

Hide/show PAD is in the MCC menu. Push tab.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: lotisully86 on December 02, 2016, 05:42:27 PM
have also gotten a CTD right at +56 min as the mcc calculated the s.v. update. froze when thread started. sorry no saved .scn 


Title: Re: Apollo 7 Beta Testing Bugs
Post by: papymaj5 on December 02, 2016, 09:37:36 PM
Here is a save a few minutes before +56


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 03, 2016, 06:19:09 AM
Thanks for the scenario. The CTD is fixed. What happened was that I simplified the MCC code a few weeks ago and it now tried to access the vessel interface for the S-IVB stage for every Apollo 7 calculation and not only the rendezvous maneuvers. That works fine as long as the S-IVB stage exists as a separate entity, which is not the case at T+56 minutes. So it tried to access a vessel that didn't exist yet.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 03, 2016, 09:24:41 AM
I have a few very minor changes to the checklist MFD's pending, so if anyone who is flying 7 right now is noticing any issues such as wrong switches or timing let me know and I will add them to my current fixes :)


Title: Re: Apollo 7 Beta Testing Bugs
Post by: macieksoft on December 13, 2016, 03:08:08 PM
I have problem with Apollo 7 LVDC++ and Apollo 11 LVDC++ scenarios.
Seems like LVDC++ bug. Maybe it exists with all LVDC++ scenarios (i have not tested scenarios other than 11 and 7).

I hate automatic LES jettisson so i always put both tower jett switches to OFF. But if i am running LVDC++ scenario tower is always jettissoned automatically several seconds after staging, even with tower jett switches set to OFF.
Is there any way to fix this or should i wait until next release?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 13, 2016, 04:26:47 PM
I have looked at the Apollo Operations Handbook and surprisingly (at least to me) it seems that the jettison motor is not firing automatically at all during a nominal ascent. Only during a Mode I abort the switch setting "AUTO" is doing something. In NASSP the SECS is not fully implemented, after all NASSP 7.0 won't really support abort maneuvers and a lot of what the SECS is doing is abort sequencing.

So the solution is removing the auto jettison from the LVDC code. The IU gets a signal when the LET has jettisoned, so maybe some more code has to be changed there. Does the IU get a signal? I'm not so sure that is the case anymore. Looks like the IGM is started at the nominal time of LET jettision, doesn't matter if the LET is still attached or not.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 13, 2016, 05:33:37 PM
I have looked at the Apollo Operations Handbook and surprisingly (at least to me) it seems that the jettison motor is not firing automatically at all during a nominal ascent. Only during a Mode I abort the switch setting "AUTO" is doing something. In NASSP the SECS is not fully implemented, after all NASSP 7.0 won't really support abort maneuvers and a lot of what the SECS is doing is abort sequencing.

So even when the TWR JET switches are in AUTO, it did not automatically fire in a nominal launch?  So what does the "AUTO" setting actually do?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 13, 2016, 06:06:10 PM
The Earth Landing Sequence Controller (ELSC) has barometric switches, which are used for drogue chute and main chute deployment during a normal landing, but during launch they are used for different abort configurations. If I understand it correctly, the LET jettision switches in Auto causes the the LET to be jettisoned automatically below 40k feet during an abort. Above that it has to be done manually. So manual jettison has to be done in late Mode 1B and Mode 1C. Above 40k feet the astronauts have the option to let the LET help stablize the aborted spacecraft for a while or jettison it right away and use the RCS. 40k is not explicitely mentioned with LET jettison, so I have to look in the Systems Handbook if that barometric switch is used for the auto jettison.

The explanation of the ELSC is in AOH Volume I section 2.9.4.14.5


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 14, 2016, 10:10:07 AM
This topic has come up before: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=848.msg3880#msg3880

It doesn't look like anything bad is happening when you don't fire the LET. No CTDs or internal stage logic problem. Apollo 7 simply doesn't make orbit because of the extra weight. The Saturn V can reach orbit and you can fire the LET then. Again no real problems. So I will remove the LET jettison from the Saturn code and the LVDC code. The LVDC code also seems to to start the IGM, when the LET is away. But I really can't find any reference for that being the case. The LVDC has a set time from Timebase 3 when the LET is supposed to be separated. At that time the IGM is allowed to be enabled. For the astronaut the cue for manual LET jettison is the S-II Sep light, which is the signal from the IU that the interstage has been separated. So it seems to me that there is no connection between IU and LET, and only an auto jettison of the LET under certain circumstances during an abort. And that will not be implemented in NASSP 7.0.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: macieksoft on December 14, 2016, 10:33:14 AM
So the solution is removing the auto jettison from the LVDC code.

Is there any way to do it on release version (without need to decompile/compile modules)?
Is there any text config file that contains the event sequence during launch with LVDC++?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 14, 2016, 10:45:25 AM
Is there any way to do it on release version (without need to decompile/compile modules)?

Why not simply download the automatically created beta release with prebuild modules? https://github.com/dseagrav/NASSP/releases/download/NASSP-V7.0-Beta-master-300/NASSP-V7.0-Beta-master-300.zip

Quote
Is there any text config file that contains the event sequence during launch with LVDC++?

Some of it is hardcoded, other variables are defined in the launch scenarios with LVDC. But there isn't a separate config file for the LVDC configuration. Do you want more information about how the LVDC event sequencing works or do you want to change some things about it or why are you asking?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: macieksoft on December 14, 2016, 03:38:33 PM
I am asking because i am akind of "experimentator" who like doing strange things with games.
I was banned from Eagle Dynamics forum (they did DCS flightsim) because i was one of the guys who found undocumented AGM-65E related avionics in DCS:A-10C :-P I was also discussing things related with JDAMs and datalink (not too many people knows how much those things were simplified in DCS).
I am just a guy who like messing around with software, thats why i sometimes ask for strange things.
I was also experimenting with NASSP. I was merging scenarios so i could launch NASSP to space station i created using various modules found over the net. I was experimeting with UMMU EVA from NASSP CM using UMMUFA addon.
I was also messing around a little with ground station software.

Knowing how LVDC++ works could be usefull for some "further mess" ;-) Also i am looking for a way to haul some custom loads in place of LM.

And i neverminded there is actualy automatic release build or whatever its called, i was thinking that using lastest version would force me to compile everything. Does it includes fixed tower jettisson bug or should i wait some time? Buildbot told me that you made this change. Thanks for fixing it.

And are the docking/rendezvous lights working? I see that Orbiter 2010 supports lights, UMMU has working lights that illuminates nearby things. This could be usefull for docking at night.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 14, 2016, 04:31:05 PM
I will always try to help with experiments, if I can.

I was merging scenarios so i could launch NASSP to space station i created using various modules found over the net. I was experimeting with UMMU EVA from NASSP CM using UMMUFA addon.

Creating a fully function scenario with Virtual AGC and LVDC++ is no simple task. For the Virtual AGC you will have to use one of the padload worksheets under Doc/Project Apollo - NASSP/GNC Tools. You will always have to generate an ephemeris with LTMFD. I should probably write a wiki article about my padload creation process. One day there hopefully will be a scenario creator for NASSP that does all these things for you.

The LVDC++ without any parameters in the launch scenario will get you into a circular Earth orbit. For anything fancy like a TLI you need to configure the launch scenario more extensive. For Apollo 11 and 14 I have the complete Launch Vehicle Operational Trajectory documents with the guidance presettings. So these launch scenarios (under Broken Scenarios/Virtual AGC) are fully configured for the complete daily launch window and the two TLI opportunities. The LVDC has a good wiki article already (http://nassp.sourceforge.net/wiki/Launch_Vehicle_Digital_Computer) and I will add a description of all the parameters for the launch scenario.

Quote
I was also messing around a little with ground station software.

It's a really nice piece of software, that currently can only display GNC related parameters, and can cause a Crew Alarm and such things. It could be expanded for a bunch of other telemetry. I have looked at the code, seems pretty complicated to me.

Quote
Knowing how LVDC++ works could be usefull for some "further mess" ;-) Also i am looking for a way to haul some custom loads in place of LM.

Custom payloads is really, really difficult right now. You would have to change some code loading the meshes etc. The three big new features for NASSP 8 are already pretty clear: Orbiter 2016 compatibility, fully functional Lunar Module and completely reworked staging. Each stage will be simulated separately and attached to the upper stages and payloads. So once the actual payloads (LM, Docking Module for ASTP etc.) are a separate entity on the pad already, then custom payloads will be much easier. And we will be able to run a mission like Apollo 5 with just a LM. Because right now the Saturn rockets and the CSM are completely integrated and not separate at all, in terms of programming.

Quote
And are the docking/rendezvous lights working? I see that Orbiter 2010 supports lights, UMMU has working lights that illuminates nearby things. This could be usefull for docking at night.

There are no lights defined, only partially in the meshes. It would indeed be very useful to have all the lights, It's probably not going to happen in NASSP 7.0 though.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 21, 2016, 10:22:55 AM
Running Apollo 7 again for good measure, just a question about the SV updates, I like the way jalex did the uplinks in Apollo 8 and I was wondering if I could mimic that in the 7 checklist so instead of asking the user to open PAMFD, it does a P27 uplink using MCC.  Thoughts?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 21, 2016, 10:54:15 AM
Yeah, I think that is a good idea. People who do not want to use the MCC, probably also wouldn't use the Checklist MFD for the whole flight. So the combination MCC+Checklist MFD is probably the most logical case.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 21, 2016, 10:55:41 AM
Yeah, I think that is a good idea. People who do not want to use the MCC, probably also wouldn't use the Checklist MFD for the whole flight. So the combination MCC+Checklist MFD is probably the most logical case.

Ok cool, now should I keep the PAMFD SV update group in there just in case?  Or change it to reflect the MCC entirely?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on December 21, 2016, 11:03:18 AM
You can leave the group in there. Maybe we still want to use it somehow, giving the user an option, creating a separate checklist file for using MFDs etc. All that doesn't have to be done now though.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 21, 2016, 11:10:40 AM
You can leave the group in there. Maybe we still want to use it somehow, giving the user an option, creating a separate checklist file for using MFDs etc. All that doesn't have to be done now though.

My thoughts exactly, I left that group as is and changed the SV updates in the flight plan to call the P27 Update group instead.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on December 22, 2016, 11:23:44 AM
So I have been running 7 again as I mentioned, and I have followed both phasing maneuvers to the letter however when the NCC1 maneuver PAD comes around, the dVC is 7909.0.  I have posted my scn and have no idea what happened.

EDIT:  So I reloaded from about 10 hours earlier and time warped at 30x until the NCC again and got a good result.  I think somehow the SIVB went haywire in a load and thus MCC could not calculate NCC1 properly.  Still do not know what happened to make the SIVB do that though!


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on January 06, 2017, 09:52:03 AM
So I am back working on this and on my 7 checklist I started what jalex did with Apollo 8, adding the name of the update to the flight plan instead of just Copy Maneuver PAD.  I think it looks better and allows the user to make sure the correct MCC update is there.  I have the names of the uplinks up to 22h but @indy91 if you have a list of the uplinks for 7 and the approximate times that would help tremendously, for now I am literally just flying the mission and changing the text when they come up.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 06, 2017, 10:03:00 AM
Abort, Abort, Abort.  :ROTFL3453:

I am already doing these changes to the Apollo 7 Checklist. I have started creating the Apollo 7 scenarios, so I might as well fix any of these checklist issues when I find them. If you want you can of course fly the mission up the point where there are scenarios (right now 26h GET) and look if you find any more checklist issues. That would then be our last check before we call Apollo 7 ready for the release.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on January 06, 2017, 10:10:36 AM
Abort, Abort, Abort.  :ROTFL3453:

I am already doing these changes to the Apollo 7 Checklist. I have started creating the Apollo 7 scenarios, so I might as well fix any of these checklist issues when I find them. If you want you can of course fly the mission up the point where there are scenarios (right now 26h GET) and look if you find any more checklist issues. That would then be our last check before we call Apollo 7 ready for the release.

Haha excellent!  I will keep going with checking out 7 then :)  Did we ever find out if Apollo 7 switched the dV LM/CSM switch to CSM for P40 burns?  I remember you discovered they left it in LM/CSM for a CSM that was not fully loaded during launch but did the subsequent P40's switch it back like on the Apollo 8 checklists?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 06, 2017, 10:17:42 AM
Did we ever find out if Apollo 7 switched the dV LM/CSM switch to CSM for P40 burns?  I remember you discovered they left it in LM/CSM for a CSM that was not fully loaded during launch but did the subsequent P40's switch it back like on the Apollo 8 checklists?

You must have misunderstood (or I said it wrong). They left it in the CSM/LM position for launch for a fully loaded CSM, not the other way around. Did you ever change that in the Apollo 7 checklist? Because it is in that position for the launch, but I wasn't sure if that was the case before. The reason for having it in the CSM/LM position for a heavy CSM is that the switch changes a few SCS TVC gains and the CSM reacts more stable (but sluggish) during a Mode III or Mode IV abort. This was the desired behavior anyway.

It's not so important right now, the switch doesn't do anything yet, because I had problems when I tested the new CSM/LM gains. The SCS Auto TVC was pretty bad then, so I didn't implement the new gains yet. Normally for a CSM alone the switch was of course in the CSM position.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on January 06, 2017, 10:25:31 AM

You must have misunderstood (or I said it wrong). They left it in the CSM/LM position for launch for a fully loaded CSM, not the other way around. Did you ever change that in the Apollo 7 checklist? Because it is in that position for the launch, but I wasn't sure if that was the case before. The reason for having it in the CSM/LM position for a heavy CSM is that the switch changes a few SCS TVC gains and the CSM reacts more stable (but sluggish) during a Mode III or Mode IV abort. This was the desired behavior anyway.

It's not so important right now, the switch doesn't do anything yet, because I had problems when I tested the new CSM/LM gains. The SCS Auto TVC was pretty bad then, so I didn't implement the new gains yet. Normally for a CSM alone the switch was of course in the CSM position.

That's what I meant yes.  I ask because the checklist for 7 and 8 both have LM/CSM for launch and I know the P40 checklist in Apollo 8 includes a switch verification to use CSM only.  Do you think 7 launched with it in the CSM position?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 06, 2017, 10:43:44 AM
Do you think 7 launched with it in the CSM position?

I thought it did, but now I don't think so anymore. We don't have the Apollo 7 AOH, but we do have the ASTP Operational Procedures document (http://hdl.handle.net/2060/19750004933). The switch is relabeled there, it is called "ATVC Gain" and has a high and low position. I very much doubt the SCS was actually reworked too much for Skylab and the ASTP, so the switch function is probably similar or identical. And the switch position for "Backup Crew Cabin Ingress" and "At Liftoff" is Low, for "Docked to Soyuz" and "Entry Preparations" it is in High. So it looks like they wanted the low gains for a Saturn IB launched CSM as well. And that means we leave the checklists like they are right now.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on January 09, 2017, 08:05:52 AM
So I wanted to ask and refine the RDV a bit more but I thought it was inappropriate to keep going in "what needs done" so I am going to ask here.

When I first call P34, the Checklist MFD says there is a F 06 37, which comes up for about 3 seconds before a F 50 18 comes up.  The checklists I have mention nothing about this.  I have hit both PRO and ENTER and usually it comes back up before finally clearing to a F 06 37.  Is this normal behavior?  Or am I missing a step/procedure.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 09, 2017, 08:41:04 AM
No idea why another F 50 18 comes up when P34 was started, but it's the same behavior for me. That never happened in Colossus249. Usually when you start P20 you get the F 50 18 and then you maneuver to the preferred tracking attitude. Once you are there you press ENTR and because a few minutes have passed the tracking attitude has moved by about 15. So you do this smaller maneuver and once you are there press ENTR again. And because the attitude is now close enough to the tracking attitude it automatically goes into the auto tracking mode and no further F 50 18 should be displayed. From now on it should track the target, with correct attitude rates and everything.

So why another V50 N18 comes up in P34 is very strange. I have even waited a long time in P20 to see if another 50 18 comes up, but it only happens once you start P34. This is something I would expect from Artemis, there you don't have to separately start P20 at all and F 50 18 is the first display in P34.  :ROTFL3453:

Also, while I said I had some better results with my rendezvous in P35 it still falls apart and I get very high numbers as the DV in Noun 49. So the problem is far from solved. It has to be something with the W-Matrix, but I thought I have tried everything...


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 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! :shock: 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 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.



Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie 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 :(


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 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?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: jalexb88 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?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 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...


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 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.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 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...


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie 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?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 10, 2017, 10:33:12 AM
I've done some testing with different AGC versions, just for V67 input parameters and scaling, and these are my results so far:

Artemis072 and Comanche055 source code is wrong about the scaling of WRENDPOS and WMIDPOS. Both are scaled as meters *2^-19 and not 2^-14. So the values and padloads are then:

WRENDPOS and WRENDVEL: 10,000 ft and 10 ft/s. Scaled: 137 and 763
WMIDPOS and WMIDVEL: 30,000 ft and 30 ft/s. Scaled: 436 and 2732

These padloaded values are now in agreement with the Apollo 16 G&C Checklist Backup Erasable Load Update. The scenarios have been using the the correct values before, but now I can also use the correct engineering values in the Pad Load Worksheet. Also note that Luminary uses the same engineering values for WRENDPOS and WRENDVEL, but a different scaling for WRENDPOS.

Colossus237 and Colossus249 are a total mystery to me. The scaling for both WRENDPOS and WRENDVEL are different than in later versions. I tend to believe the Apollo 8 CMP checklist that R1 in Noun 99 is in 0.01 Nautical Miles. This is true until Comanche055, for which there is a Program Change Request to change the values in V67 to ft and ft/s. But how the scaling works, no idea. I guess I have to test it some more. For example, when I use +01000, +00100 and +00001 in V67 then WRENDPOS and WRENDVEL become 516 and 440. Makes no sense really when I take the scaling in the source code, but also not really when I assume NM and ft/s as the units.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 on January 10, 2017, 11:24:20 AM
I've just tried around a little and settled to:
N99
R1 +00020
R2 +00010
R3 +00001

R1 makes some sense to me - 2 NM are about 12000 ft. R2 doesn't have such a big effect as it seems. dV/dR settle as quick with 1 fps as with 10 fps. The dV for the first mark is just bigger, that is all. All in all, the more the marks, the better. I made 60 marks for fun and in the end the CMC put the SIVB right in the middle of the crosshairs -not that I recommend such a 'gun fight'. :wink:
Sequence with V67 is always V67 - enter data - V93. Otherwise the w-matrix remains unchanged. Oh, and no, don't do a V93 after P34 -messes up big time...


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 10, 2017, 03:09:08 PM
+00020 would be 0.2 NM and not 2.0 NM, but I understand what you mean.

I tried these values and I got a good TPI phase, the same behavior that I have always been getting before. TPI was about 1 ft/s short of the PAD value and I got pretty large MCCs. 10 ft/s for MCC1, 6 ft/s for MCC2. I wonder, is the "phoney" S-IVB mark really necessary in Colossus? Does it maybe throw off the S-IVB state vector? The Apollo 11 CSM Rendezvous Procedures uses a V93 for MCC1 and MCC2, each time when P35 was just started up. But the Apollo 7 rendezvous first updates the S-IVB state vector and then in P35 the CSM state vector, while during a normal lunar rendezvous always the LM state vector was updated. So there might be a difference. I also remember that I got 10 ft/s MCCs half of the time or more, but quite often I almost had to do no MCCs at all.

I will test some more what went wrong for me earlier, try to find the scaling for the rendezvous W-Matrix values and then maybe change the initialization parameters in the launch scenario or maybe just add a V67 in the Checklist MFD rendezvous procedures. At least a V93 should be done.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 on January 10, 2017, 04:01:57 PM
Quote
+00020 would be 0.2 NM and not 2.0 NM, but I understand what you mean.
Okay, then it's 1200 ft, almost those 1000 ft the rendezvous doc prescribes.
Quote
I wonder, is the "phoney" S-IVB mark really necessary in Colossus?
Nope. I guess it was made test if marking on the wrong SV (being 'phoney') would lead to bad dV/dR, so that such a mistake could be recognized. When I remember right, the dV/dR on that mark should be rejected, so the LM SV doesn't get messed up.
Quote
But the Apollo 7 rendezvous first updates the S-IVB state vector and then in P35 the CSM state vector, while during a normal lunar rendezvous always the LM state vector was updated.
Of course. You'd always update the SV of the vehicle that has actually performed the maneuver. During a normal rendezvous, the LM would do all the burns, so that SV had to be updated.
Quote
The Apollo 11 CSM Rendezvous Procedures uses a V93 for MCC1 and MCC2, each time when P35 was just started up.
Really? The flight plan doesn't mention it. Artemis' MINKEY doesn't do it either, AFAIK.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 10, 2017, 04:24:11 PM
Quote
I wonder, is the "phoney" S-IVB mark really necessary in Colossus?

Nope. I guess it was made test if marking on the wrong SV (being 'phoney') would lead to bad dV/dR, so that such a mistake could be recognized. When I remember right, the dV/dR on that mark should be rejected, so the LM SV doesn't get messed up.

Absolutely right! The V32 to reject that mark is even in the rendezvous procedures document. I did it wrong all along.

Quote
Quote
The Apollo 11 CSM Rendezvous Procedures uses a V93 for MCC1 and MCC2, each time when P35 was just started up.

Really? The flight plan doesn't mention it. Artemis' MINKEY doesn't do it either, AFAIK.

The Apollo 12 CSM Rescue Book has the V93. Seems like you almost always do a V93, V57, V87 in this order at the beginning of a normal marking sequence. V87 allows VHF range to be processed.

When and how to do a V93 is one of the more complicated aspects of MINKEY. Read from page 5.2-83 here: http://www.ibiblio.org/apollo/Documents/HSI-208454.pdf


Title: Re: Apollo 7 Beta Testing Bugs
Post by: eddievhfan1984 on January 10, 2017, 08:18:53 PM
Holy crap, been doing it wrong the whole time, too. LOL I didn't know I had to reject the phony mark after making it. I thought it just drove the state vector to the limits of the W-Matrix, and subsequent markings re-stabilized it.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 11, 2017, 07:06:47 AM
Don't get your hope too much up, there still is Average G and the CSM and S-IVB state vectors shouldn't be too bad after TPI anyway, even without more marks. I just haven't been too careful with the "phoney" mark in the past. But now I at least know the procedure: do the single S-IVB mark, wait 15 seconds for processing, PRO, wait until the 16 49 comes up, reject with V32E, then V81E, V57E and then the normal marking sequence is done.

EDIT: I found the scaling of the W-Matrix initialization parameters! There is an additional factor that I managed to find in the source code. That factor is 1/sqrt(3), which is about 0.57735. If I then take the parameters I used for testing then the register 1 +01000 is 10.00NM and scaled 516, register 2 is 10 ft/s and 440 scaled. And just like the later AGC versions the basic scaling is not 2^-14 for the positions but 2^-19. I'm not sure if I can ever trust AGC source code again. This scaling also applies to the P22 and P23 parameters in C237 and C249.

If I then reverse engineer the rendezvous parameters used before then I get about 29000 ft and 17 ft/s. That's probably a bit much. The suggested parameters for Apollo 10 (I have no other source than a Tindallgram for that) are 10000 ft and 10 ft/s. I will try if these parameters are any good. And then for the last marking sequence we know that the parameters were changed to 1000 ft and 1 ft/s. So if everything works out then I'll add that change (no V67, directly in the erasable memory) as well. Also, all the scenarios I have created so far have to be changed as well. It's only two EMEMs, so not too bad.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 on January 11, 2017, 08:51:03 AM
Quote
This scaling also applies to the P22 and P23 parameters in C237 and C249.
...but those are good? Don't forget that there are such thingies like ALTVAR and INTVAR, too...
BTW, do you understand how this ranging thing works (hardware-wise, I mean)? The CMC has 4 bits in output channel 13, obviously to tell the range unit what to do -but how does the actual range get into the CMC? There is no input channel or such for it. :?


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 11, 2017, 09:30:49 AM
Quote
This scaling also applies to the P22 and P23 parameters in C237 and C249.
...but those are good? Don't forget that there are such thingies like ALTVAR and INTVAR, too...

The rendezvous parameters were also good in the past. I have the feeling that I still don't know the actual problem with my scenario...

Quote
BTW, do you understand how this ranging thing works (hardware-wise, I mean)? The CMC has 4 bits in output channel 13, obviously to tell the range unit what to do -but how does the actual range get into the CMC? There is no input channel or such for it. :?

There are a few input and output bits, but the actual range is shifted to register 46 (RNRAD) when the CMC requests it.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 on January 11, 2017, 05:33:43 PM
Quote
There are a few input and output bits, but the actual range is shifted to register 46 (RNRAD) when the CMC requests it.
Okay, who would look there...
After some tests, I don't object against V93E after each maneuver. It doesn't hurt on one hand; doesn't improve SV accuracy significantly on the other. Zero-sum game IMHO.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 12, 2017, 12:55:14 PM
I've finally settled for the rendezvous parameters. They are 1000 ft and 1 ft/s. 10x these values as the initial numbers don't work too well. I have pushed the update: Pad Load Worksheets with the now known scaling, a revised Apollo 7 Checklist MFD file, I fixed all Apollo 7 scenarios to have the new parameters and I added three new scenarios.

Now that this rendezvous madness is over I can finally return to creating the release scenarios. Those will take a while and if nobody wants to fly a Apollo 8 mission good enough to be without errors for the release, then I will do Apollo 8 after that.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: meik84 on January 13, 2017, 02:10:55 PM
I just tried V87 just for fun. Seems to lead to some sort of 'hang up' -the CMC won't process any marks after that. I guess R22 gets stuck in a loop of some sort, as there is a 'data good' discrete, but no range in RNRAD. I suggest we set (inverted logic!) Bit 2 of channel 33 permanently for now, so that everybody who tries V87 gets what he deserves: the TRACKER light! :wink:


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on January 14, 2017, 11:00:33 AM
I know this is a trivial point but for the sake of realism and continuity, shouldn't Apollo 7 and 8 EMS on CSM/LV SEP be set to zero and not -100?  I know they changed it in later missions because of sudden, erroneous jump but of course our sim does not have that.  Just a thought :)


Title: Re: Apollo 7 Beta Testing Bugs
Post by: indy91 on January 14, 2017, 11:20:00 AM
Sure. If you want to fix it, here a link to the new Apollo 8 TLI checklist: https://drive.google.com/open?id=0BzUu_aREm1xSN2VWeE5ub2x3Zjg I'll fix it in the Apollo 7 checklist.


Title: Re: Apollo 7 Beta Testing Bugs
Post by: rcflyinghokie on January 14, 2017, 11:24:15 AM
Sure. If you want to fix it, here a link to the new Apollo 8 TLI checklist: https://drive.google.com/open?id=0BzUu_aREm1xSN2VWeE5ub2x3Zjg I'll fix it in the Apollo 7 checklist.

Oh wonderful!  I will check through our 8 procedures and make any necessary changes :)