Meadville Space Center
Welcome, Guest. Please login or register.
October 24, 2020, 08:38:08 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 Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  What needs done?
« previous next »
Pages: 1 ... 46 47 [48] 49 50 ... 56 Print
Author Topic: What needs done?  (Read 74707 times)
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #705 on: August 27, 2016, 05:52:17 PM »

This procedures document has the 5.0 deadband, but it also changes it to 0.5 before MCC-1 at the latest. The CMC is not too good at doing the 5.0 deadband attitude hold, especially because the dynamics the AGC assumes and the fully loaded NASSP CSM are differing. So usually its going back and forth in the deadband and is not saving much propellant in comparison to the narrow deadband. Is the 5.0 good or bad for the P23s?
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #706 on: August 27, 2016, 10:42:45 PM »

I'd say it's bad, since you gotta keep the LLOS pointed as stable as possible, to avoid state vector errors. 5 degrees would mean that the landmark could drift out of the sextant before ti was corrected...
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #707 on: August 28, 2016, 04:33:10 AM »

I'd say it's bad, since you gotta keep the LLOS pointed as stable as possible, to avoid state vector errors. 5 degrees would mean that the landmark could drift out of the sextant before ti was corrected...

This is pretty true, but I do wonder why this deadband is set up after LV SEP and if subsequent missions did the same.  And also if they changed it prior to the first P23.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #708 on: August 28, 2016, 04:48:11 AM »

This is pretty true, but I do wonder why this deadband is set up after LV SEP and if subsequent missions did the same.  And also if they changed it prior to the first P23.

The Apollo 13 flight plan often mentions the DAP load and the flight plan for all later missions has it on almost every page. On Apollo 13 they loaded 21111 after the CSM/LM Ejection, but for the P23s they changed it to 21101, so 0.5 deadband. 21101 seems to be the preferred configuration during TLC. I'd say we use the Apollo 13 way, first load 11112 after separation from the S-IVB and then 11102 before the P23s. Well, looks like there is not really much time between separation and P23s, so maybe load 0.5 deadband immediately. I don't mind either way.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #709 on: August 28, 2016, 07:25:18 PM »

The Apollo 13 flight plan often mentions the DAP load and the flight plan for all later missions has it on almost every page. On Apollo 13 they loaded 21111 after the CSM/LM Ejection, but for the P23s they changed it to 21101, so 0.5 deadband. 21101 seems to be the preferred configuration during TLC. I'd say we use the Apollo 13 way, first load 11112 after separation from the S-IVB and then 11102 before the P23s. Well, looks like there is not really much time between separation and P23s, so maybe load 0.5 deadband immediately. I don't mind either way.

I will play with them and see what flow works best, but I am thinking that is the way to go.  I will edit them when jalex finishes the second half of Apollo 8 and I tweak a few other pieces of the checklist.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #710 on: August 30, 2016, 05:41:30 AM »

A few smaller updates:

-LGC FDAI error needles signal now is set to zero, if the error counter isn't enabled. This behavior is identical to the CMC now.
-One of the CSM FDAI error needles was accidentally changed, this is fixed now.
-The LVDC can perform an attitude maneuver in Timebase 5 now. Unfortunately the inhibits for this were previously not set, so all old scenarios might try to move to separation attitude in Earth Parking Orbit. If this annoys you a lot, then find and change these lines in the scenario to:

LVDC_INH1 1
LVDC_INH2 1

The inhibits should be set for all S-IVBs going to the moon. They were not doing an attitude maneuver in Timebase 5. The inhibits were also probably set for Apollo 9 and then removed via an MCC IU uplink. In the now changed Apollo 9 scenario the inhibits are simply zero from the beginning. I guess if we ever have proper IU telemetry, then we could change this. So the LVDC should by default now behave as before and only the Apollo 9 scenario will move to sep attitude in Timebase 5. The LVDC currently gets destroyed when separating from the S-IVB. If we change it so the S-IVB is still controlled by the LVDC after sep, then Apollo 9 gets really complicated. Very Happy They did two reignitions on that mission. But I would really like to see this in NASSP one day:

Quote
004:46:03 Roosa: We show ignition on the S-IVB.

004:46:06 Schweickart: It's on the way.

004:46:15 McDivitt: It's just like a bright star disappearing into the distance.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #711 on: September 04, 2016, 09:26:58 AM »

A few smaller updates:

-LGC FDAI error needles signal now is set to zero, if the error counter isn't enabled. This behavior is identical to the CMC now.
-One of the CSM FDAI error needles was accidentally changed, this is fixed now.
-The LVDC can perform an attitude maneuver in Timebase 5 now. Unfortunately the inhibits for this were previously not set, so all old scenarios might try to move to separation attitude in Earth Parking Orbit. If this annoys you a lot, then find and change these lines in the scenario to:

LVDC_INH1 1
LVDC_INH2 1

The inhibits should be set for all S-IVBs going to the moon. They were not doing an attitude maneuver in Timebase 5. The inhibits were also probably set for Apollo 9 and then removed via an MCC IU uplink. In the now changed Apollo 9 scenario the inhibits are simply zero from the beginning. I guess if we ever have proper IU telemetry, then we could change this. So the LVDC should by default now behave as before and only the Apollo 9 scenario will move to sep attitude in Timebase 5. The LVDC currently gets destroyed when separating from the S-IVB. If we change it so the S-IVB is still controlled by the LVDC after sep, then Apollo 9 gets really complicated. Very Happy They did two reignitions on that mission. But I would really like to see this in NASSP one day:

Quote
004:46:03 Roosa: We show ignition on the S-IVB.

004:46:06 Schweickart: It's on the way.

004:46:15 McDivitt: It's just like a bright star disappearing into the distance.

Ever since this was implemented when i fly the A9 scenerio, the CSM kicks itself into STBY an RESTART.  It appears to do it when the timebase changes as it did when inserted into EPO and I was able to restore it and then when the booster maneuvers to SEP attitude it does it again and will not free up.  I have attached the scn.

* Apollo 9 Virtual AGC LVDC++ - Launch 0003.scn (102.6 KB - downloaded 54 times.)
Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #712 on: September 05, 2016, 04:12:13 AM »



Ever since this was implemented when i fly the A9 scenerio, the CSM kicks itself into STBY an RESTART.  It appears to do it when the timebase changes as it did when inserted into EPO and I was able to restore it and then when the booster maneuvers to SEP attitude it does it again and will not free up.  I have attached the scn.
[/quote]

This seems to be occurring in all scenarios. Have specifically noticed it occurs after Verb 46 dap enable. Holding PRO for 5 seconds, RSET and V37E00 clears the standby, reset, and Cmc warning lights, but the dap doesn't appear to be functioning correctly, or at all, from what I can tell. Hope this helps
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #713 on: September 05, 2016, 04:34:27 AM »

The most recent Virtual AGC engine change seems to be at fault. I'll take a look if I screwed something copying over that change to our modified file. If not I'll reopen the LGC issue on the Virtual AGC github page and ask for a LGC fix that doesn't break the CMC.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #714 on: September 05, 2016, 06:58:38 AM »

This seems to be occurring in all scenarios. Have specifically noticed it occurs after Verb 46 dap enable. Holding PRO for 5 seconds, RSET and V37E00 clears the standby, reset, and Cmc warning lights, but the dap doesn't appear to be functioning correctly, or at all, from what I can tell. Hope this helps

Yeah I re-flew that one and it happens at both DAP load changes.  Good catch there.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #715 on: September 05, 2016, 07:04:48 AM »

I have to yet to reload a scenario where it doesn't happen to the CMC. I guess right now beta release 206 is the stable one for the CMC and release 207 for the LGC.  ROTFL I've check the changes to the AGC engine again and they are identical to the official Virtual AGC change. So it's either caused by any of the NASSP modifications to the agc_engine.c file being incompatible with the TIME6 fix, or something is wrong with that change in general.

EDIT: I have tracked down the cause of the standby and restart lights. Is there actually any problem with the CMC other than that the lights shouldn't be on? All I can see here is that the lights are turned on when they shouldn't, but the CMC should be fully functional.

EDIT2: For some reason whenever a T6RUPT is triggered 37777 is written to output channel 13, which is the cause of the lights and maybe other problems. Now I'll wait for the response of the Virtual AGC developers.
« Last Edit: September 05, 2016, 09:03:08 AM by indy91 » Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #716 on: September 05, 2016, 09:40:31 AM »


EDIT: I have tracked down the cause of the standby and restart lights. Is there actually any problem with the CMC other than that the lights shouldn't be on? All I can see here is that the lights are turned on when they shouldn't, but the CMC should be fully functional.


That's the original conclusion I came to as well. All programs and routines that I have tried work as they should, I only assumed something could be wrong with the dap because a.) the warning lights occur with Verb 46 and b.) after clearing the lights I tried a verb 49 auto maneuver but could only maneuver manually, only tried it once though and could very well be operater error. I just figured if the v46 was causing the lights then the dap wasn't activating properly
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #717 on: September 05, 2016, 10:40:29 AM »

Writing all 1s to output channel 13 certainly does have more effects than just two lights. Actually, P63 of the LGC was asking the landing radar for range data way too early in the descent. That is probably also caused by this issue.

EDIT: Should be solved now. Now let's try if this changes anything about the lunar descent...
« Last Edit: September 05, 2016, 11:30:47 AM by indy91 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #718 on: September 19, 2016, 05:20:57 AM »

I found the problem with the LVDC scenario loading. The LVIMU parameters are loaded in the LVDC loading function after the LVDC parameters are loaded. So after the string "LVDC_END" it expects "LVIMU_BEGIN". What it actually currently reads there is the first line of the CMC padload, "CMPAD0110 1144". That is not the expected string, so it isn't loaded for the LVIMU. The scenario loading is then continued and because the Orbiter API function "oapiReadScenario_nextline" is always going to the next line in the scenario file, it has now skipped the line "CMPAD0110 1144". That's why EMDOT is not loaded and during a SPS maneuver the CSM mass isn't decreased. I'm going to fix this by simply adding the lines

Code:
LVIMU_BEGIN
LVIMU_END

to the LVDC launch scenario files. That way the LVDC loading has the expected structure, even if no parameters are loaded for the LVIMU. The more elegant solution would be loading the LVDC parameters like the AGC padloads, which don't use the normal save/load functions for the initial scenario loading. The LV Operational Trajectories even have the octal adresses in the LVDC memory for the parameters, which would be one way to do it. But for now the solution above works.
Logged
kneecaps
Project Team Member
Full Member
****
Posts: 217


36711000 kneecaps@shockpulse.co.uk
View Profile
« Reply #719 on: September 19, 2016, 04:05:00 PM »

I found the problem with the LVDC scenario loading. The LVIMU parameters are loaded in the LVDC loading function after the LVDC parameters are loaded. So after the string "LVDC_END" it expects "LVIMU_BEGIN". What it actually currently reads there is the first line of the CMC padload, "CMPAD0110 1144". That is not the expected string, so it isn't loaded for the LVIMU. The scenario loading is then continued and because the Orbiter API function "oapiReadScenario_nextline" is always going to the next line in the scenario file, it has now skipped the line "CMPAD0110 1144". That's why EMDOT is not loaded and during a SPS maneuver the CSM mass isn't decreased. I'm going to fix this by simply adding the lines

Code:
LVIMU_BEGIN
LVIMU_END

to the LVDC launch scenario files. That way the LVDC loading has the expected structure, even if no parameters are loaded for the LVIMU. The more elegant solution would be loading the LVDC parameters like the AGC padloads, which don't use the normal save/load functions for the initial scenario loading. The LV Operational Trajectories even have the octal adresses in the LVDC memory for the parameters, which would be one way to do it. But for now the solution above works.

Ohhhh. Nice catch. Certainly explains the behavior!
Logged

"Okay. As soon as we find the Earth, we will do it."
- Frank Borman, Apollo 8

Current Work: ?? What next??

Future Work:
I know the AGC pretty well so anything need doing there?

On Hold/Completed:
SPS TVC in P40 issues.
P11 FDAI Error Needles (98%) complete. Comitted. Working A7 scenario.
P06 AGC Standby. Concluded. It's done by the AGC PSU.
Got us a complete AOH Volume II
Pages: 1 ... 46 47 [48] 49 50 ... 56 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!