Meadville Space Center
Welcome, Guest. Please login or register.
October 25, 2020, 06:05:00 AM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
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)
| | |-+  Virtual AGC
« previous next »
Pages: 1 ... 49 50 [51] 52 Print
Author Topic: Virtual AGC  (Read 166156 times)
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #750 on: March 25, 2017, 11:39:35 AM »

Question on the implementation of the P06.  I am using it in Apollo 9 and it goes into standby with no problem.  However, when it is brought out of standby, the checklists I have say it is supposed to trigger not only a PROG light, but also a RESTART light and a CMC C/W indicator.  Is there a reason it is not doing this?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #751 on: March 25, 2017, 01:03:53 PM »

Question on the implementation of the P06.  I am using it in Apollo 9 and it goes into standby with no problem.  However, when it is brought out of standby, the checklists I have say it is supposed to trigger not only a PROG light, but also a RESTART light and a CMC C/W indicator.  Is there a reason it is not doing this?

The AOH Volume II only says that it is possible for these lights to come on, but not that it has to happen every time. So I guess whatever can cause them isn't simulated, some sort of transient maybe. @thewonderidiot is looking into it, if something on the Virtual AGC side isn't properly simulated for that yet.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #752 on: March 25, 2017, 05:24:05 PM »

Ah ok makes sense.  I was going by the different gnc checklists they didn't say possible lights I read it as if they are expected.  Good to know.  The rest of the p06 works well with Apollo 9 in orbiter 16 so far.
Logged
thewonderidiot
Full Member
***
Posts: 48



View Profile
« Reply #753 on: March 25, 2017, 06:56:45 PM »

Alright, to answer your question more specifically:

PROG: This light is entirely under software control, so without knowing which alarms might occur, it's impossible to say what might be wrong.
RESTART: The RESTART light is forcibly prevented from turning on when leaving STANDBY until timepulse 10 of GOJ1. At this point, the signal that sets the RESTART light (GOJAM) has been comfortably off for a while. If the RESTART light were to come on, that means the AGC was powered back up long enough to execute at least a full instruction, and then for some other reason (power transients etc.) took another reboot. VirtualAGC isn't simulating anything to that level of detail, so the normal case of no RESTART is expected.
CMC: This light isn't currently simulated at all by VirtualAGC itself, partly because our standalone AGC/DSKY doesn't a window for that light, and partly because we don't yet have any copies of the schematics for AGC module B8, which housed the warning filter that drove this light (though we hope this situation will change in the near future). Anyways, standby also doesn't directly affect this light, and any instances of it turning on would be related to the aforementioned possible restarts caused by power transients or other things of that nature.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #754 on: March 25, 2017, 07:29:09 PM »

Alright, to answer your question more specifically:

PROG: This light is entirely under software control, so without knowing which alarms might occur, it's impossible to say what might be wrong.
RESTART: The RESTART light is forcibly prevented from turning on when leaving STANDBY until timepulse 10 of GOJ1. At this point, the signal that sets the RESTART light (GOJAM) has been comfortably off for a while. If the RESTART light were to come on, that means the AGC was powered back up long enough to execute at least a full instruction, and then for some other reason (power transients etc.) took another reboot. VirtualAGC isn't simulating anything to that level of detail, so the normal case of no RESTART is expected.
CMC: This light isn't currently simulated at all by VirtualAGC itself, partly because our standalone AGC/DSKY doesn't a window for that light, and partly because we don't yet have any copies of the schematics for AGC module B8, which housed the warning filter that drove this light (though we hope this situation will change in the near future). Anyways, standby also doesn't directly affect this light, and any instances of it turning on would be related to the aforementioned possible restarts caused by power transients or other things of that nature.

Well the PROG light comes up, and being under software control that makes sense.  And thank you for the explanation it makes a lot of sense!

Also, I don't know if this is a known bug, but quicksaving during a P06 brings back the state with the 50 25 and 00062 in R1 with the STBY light lit, instead of the blanked out display that occurs when P06 is first started.
Logged
thewonderidiot
Full Member
***
Posts: 48



View Profile
« Reply #755 on: March 25, 2017, 07:47:45 PM »

Yeah, there's a bit of known weirdness around that stuff. One of the things I'm working on now is making all of the static things in agc_engine.c non-static and part of the state structure, which should solve all of those issues.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #756 on: June 01, 2017, 03:56:26 AM »

The last few days I have been working on creating a padload for Apollo 5, using Sunburst120. Right now there isn't much hope for launching a running Lunar Module on a Saturn, simply due to how our CSM and Saturns are working. However, while reading how Sunburst is working, I noticed that it is connected to the IU like a CMC. So, it gets a Liftoff signal via an input channel bit, just like a CMC would during a manned mission with a CSM. So I decided to try running Sunburst120 like a CMC, in a CSM. I had to hack in a few changes in the NASSP code for that to work, mostly AGC clock initialization and PIPA scaling, which is different for the LGC.

I modified the launch scenario so that I would get the CSM cockpit at T-4h, as usual. Then I didn't really know how to do anything in Sunburst. Verb 37 is broken in Sunburst, the source code actually says: **FIX LATER** Very Happy

Sunburst seems to have launch programs similar to a CMC. To start those you have to use the Extended Verb for the test programs (Verb 57) with the option code 7 for gyrocompassing. Then the familiar sequence is started, with Program 01 torquing the IMU to the desired launch alignment. Then Program 02 starts, awaiting launch. At T-5 seconds Guidance Reference Release is happening in the IU and the AGC also gets a signal for this. However, it seems a command was uplinked at this time, too, or else the launch programs don't start. The command is Verb 65 and has to be done a T-5 seconds. The AGC then quickly goes to P04, then P07 and when the liftoff discrete is sent from the IU the familiar Program 11 is started.

During the launch phase I had multiple failed attempts. Program 11 keeps running until a specific time (padload) after launch, which is supposed to be the same time as tower jettison during a normal Saturn IB launch. At that time it switches to Program 12 and starts monitoring for S-IVB engine cutoff (lack of acceleration).  The AS-206 Testing Padload document (https://www.ibiblio.org/apollo/Documents/Prelaunch%20Erasable%20Memory%20Load%20Definition%20for%20AS206.pdf) has a switch time to P12 about 15 seconds earlier than the usual tower jettison, so P12 started before S-IVB thrust buildup and it immediately recognized that as S-IVB cutoff. So I just had to move this padloaded time a few seconds back.

When P12 doesn't measure any large acceleration anymore, which is the case after orbital insertion, it starts P13. At this time I saved the scenario and started my Dr. Frankenstein work. I replaced all the Saturn and CSM stuff from the scenario with that of a running LM, from my Apollo 15 Pre-PDI scenario. And it seems to be working pretty well! I have attached the scenario to this post. There only is a LM in the scenario, but of course the LGC thinks it's still attached to the S-IVB. About 28 minutes after orbital insertion the LGC will switch to P00. Also at a predefined time (about T+50 minutes) Program 14 is started. 5 minutes later, in preparation for SIVB/LM sep, Sunburst fires thrusters for an ullage burn, and to get away from the S-IVB. At this time I still had no idea if the LM had a good alignment or state vector, and I am still not 100% sure about that.

After sep, the LM does its first attitude maneuver for "DPS cold soak". Sunburst calculates the attitude for that with the constraints: "LM X-AXIS NORMAL TO THE ECLIPTIC PLANE, AND BISECTOR OF LM +Z/-Y AXES TOWARD THE SUN." And that actually seems to be what the LM was doing! So that gave me a little bit of confidence in state vector and IMU alignment. The DAP was also working pretty well.

The next step was 3 hours of coasting. The DAP went into maximum deadbad, so not a lot of thruster activity. At T+003:55:08.50 (according to the Spacecraft Operational Trajectory, a little bit later on my attempt) Sunburst starts the programs for the first DPS burn. Again I won some confidence in the state vector and alignment, because the LM moved close to the expected attitude for the DPS burn (mostly prograde). P31 started and then P41. I wasn't quite sure what I had to do as a stand-in for the LM Programer, so I armed the descent engine. Everything up to ignition worked very nicely, including ullage burn. And then I got program alarms. The actual Apollo 5 mission also got into trouble at this exact point, but surely for other reasons. No ignition happened and I got 1103 and 316 alarms.

Here is where I need some help. The alarm data, usually Noun 08, doesn't seem to be the same in Sunburst. All I could find was Noun 31 "ALMCADR, ALMCADR +1, ERCOUNT". Here I got:

V05 N31

R1: 2001
R2: 16003

But not sure if that is correct. I don't really know how to read this. I have also attached a scenario shortly before Sunburst starts P31, in preparation for the DPS burn.

EDIT: It doesn't like my scenarios, so I will try to attach them later.



As a reference to the description above, here a list of Sunburst programs, used during a flight:

P00: LGC Idling
P01: Pre-launch Initialization
P02: Pre-launch Gyrocompassing
P04: Terminate Gyrocompassing
P05: Pre-launch System Test
P07: Pre-launch Inertial
P11: Pre-LET Jet Boost Monitor
P12: Post-LET Jet Boost Monitor
P13: Coast: SIVB Attached
P14: SIVB/LM Separation
P15: Coast: DPS Cold Soak
P27: LGC Update
P31: Pre-DPS1
P32: Pre-DPS2
P34: Pre-APS2
P41: DPS1 Burn
P42: DPS2 Burn-Braking
P43: DPS2 Burn-Approach
P44: DPS2 Burn-Random Throttle
P46: APS2 Burn
P47: Contingency APS2
P71: Suborbital Abort
P72: Contingency Orbit Insertion
P74: FITH/APS1 (Nominal FITH test)
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #757 on: June 01, 2017, 08:53:28 AM »

Well, I've been digging through the assembly info.

The 316 alarm indicates that a computer restart was triggered, but the currently running program couldn't be restarted.
The 1103 alarm is our old friend, the CCSHOLE alarm, indicating that an unused branch of the CCS instruction was run (suggesting a problem with a loop counter). This is the alarm that was killing us during the LR implementation.

The noun 31 readout provides the information as to what instruction called the alarm handler. The ALMCADR is the stored memory address of the routine that made the call (specifically, its return address from the Q register), and the ALMCADR+1 should be the instruction fetched from the next memory word after the address in ALMCADR. ERCOUNT is more than likely a running tally of alarm calls of this type (ALARM2). What's really annoying is that while we get the 12-bit address reference, we don't get the indicator of which fixed-memory bank it's in, which is making my ability to backtrace it hard. At the very least, I know it's in a reduced memory address (S-register) of 2001, with the fetched instruction from memory location 2002 being 16003. The instruction reads as TCF 6003, a jump to the ABORT2 routine in the abort/alarm handler. Now I ust need to figure out where the heck the troublesome instruction is.

Did you get any indication that ignition actually started before the alarms occurred (and then there was a subsequent shutdown), or did the DPS fail to ignite at all?
« Last Edit: June 01, 2017, 09:05:42 AM by eddievhfan1984 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #758 on: June 01, 2017, 09:06:35 AM »

Did you get any indication that ignition actually started before the alarms occurred (and then there was a subsequent shutdown), or did the DPS fail to ignite at all?

It starts the engine for a split second and immediately commands the engine off again. Not really long enough for the thrust failure routine to be the issue. I think it rather has to do with guidance, navigation or control. The LGC is supposed to start steering at DPS ignition and it isn't happy about something at that time, it seems.

EDIT: Attachments don't seem to work, here a Dropbox link with two scenarios: https://www.dropbox.com/sh/c53v37w29yyw5fj/AADJ4uY8r7lsBA0w40U9SJTLa?dl=0 The first one is the one I edited, so it's not long after orbit insertion. The 2nd scenario is shortly before the LM moves into attitude for the DPS burn, which happens about 5-6 minutes after the scenario starts.
« Last Edit: June 01, 2017, 09:15:51 AM by indy91 » Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #759 on: June 01, 2017, 10:34:45 PM »

I just tried to start the pre-DPS1 scenario, but the scenario started with a 212 alarm, indicating that PIPA bias failed and the PIPAs are inhibited. Did you have the same thing happen, indy?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #760 on: June 02, 2017, 02:29:20 AM »

I just tried to start the pre-DPS1 scenario, but the scenario started with a 212 alarm, indicating that PIPA bias failed and the PIPAs are inhibited. Did you have the same thing happen, indy?

No, I never got that alarm. Weird. I don't think any of the code changes I temporarily did to make Sunburst work in the CSM should be causing the difference in behavior. For some dumb reason I used my development branch for implementing proper CDUs for the Sunburst testing, maybe I did some other change to the IMU that I forgot about. I'll test the scenario with the normal Orbiter2016 branch.

EDIT: I do not get any alarm in the Orbiter2016 branch, when I start the "Apollo 5 - Sunburst120 with LM 0004.scn" scenario.
« Last Edit: June 02, 2017, 02:35:23 AM by indy91 » Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #761 on: June 02, 2017, 06:56:01 AM »

I just re-ran the scenario in my 2016 branch, same 212 alarms. I confirm the 316 and 1103 alarms after engine start, and I get an automatic 05 35 display, the "inbit message". I presume that has to do with the ground commands... In addition, when I start the scenario, the panel 1 mission timer is not running, and I have to manually restart it, and is it normal that ADI 2 has to slew to the S/C attitude while ADI 1 doesn't?

The 212 alarm's associated ALMCADR locations are 2737 and 24006. I confirm the same ALMCADR for the 316 and 1103 alarms.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #762 on: June 02, 2017, 07:07:35 AM »

We fixed the DPS burn issue! It was a missing padload for the gimbal trim drive, wasn't mentioned anywhere. Instead of +0 you have to load -0 (so 77777). Then it worked flawlessly! Thanks so much to Thymo and thewonderidiot for the help!

The orbit after the burn is almost exactly as it should be according to the Spacecraft Operational Trajectory. That gives me a lot of confidence in the state vector and IMU alignment. I have updated the scenarios in the Dropbox link above and added a scenario short before the second DPS burn, half an hour after DPS-1. That one also causes a bunch of program alarms. But we are now one step further.

In addition, when I start the scenario, the panel 1 mission timer is not running, and I have to manually restart it, and is it normal that ADI 2 has to slew to the S/C attitude while ADI 1 doesn't?

If the mission timer isn't running in the LM then you don't have one of my latest updates, where that is fixed.

I copied over the state of the LM from my Apollo 15 scenario, which is a little dated by now. Saving and loading the state of FDAI 2 was still missing then. So that will only happen in the post-insertion scenario.

Still no idea what causes the 212 for you though...
« Last Edit: June 02, 2017, 10:43:30 AM by indy91 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #763 on: June 02, 2017, 10:58:36 AM »

More progress. The target vector for the DPS-2 burn, which I have taken from the Spacecraft Operational Trajectory, is actually in the wrong coordinate system. So I have reverted to the AS-206 Test Padload and that vector is working much better. A few more changes I had to do:

-inhibit DAP off test. Apparently during the long DPS-2 burn the DAP can be turned off for a few seconds, during which some special stuff is written to the downlink. This test isn't really working, it seems, because the DAP never gets turned on again and the LM spins out of control. So I have inhibited that test and the DAP continues to operate.
-LM mass. Because LM-1 flew without legs, the mass of our NASSP LM is about 1000kg higher than what the LGC expects and what LM-1 actually had. The empty mass is essentially hardcoded right now, so you can change that by going to the file "lemmesh.cpp", function SetLmVesselHoverStage() and change the 2nd line to:

Code:
SetEmptyMass(AscentFuelMassKg + 3760.0);

With these changes (also updated in the Dropbox folder) I had a pretty good second DPS burn. It's essentially a powered descent simulation. There is a braking phase (P42) during which you mostly have full throttle. Then an approach phase (P43) with a lower throttle setting. After that a random throttle commands sequence is start (P44). At the end of this full throttle is commanded and 1 second later abort staging is commanded, and the Fire In The Hole (FITH) test starts, with DPS running, then abort staging and APS start. That's where I am currently at, because the APS burn program (P74) isn't started for some reason. It should be monitoring the Stage Verify bit (channel 30, bit 2). So that's what I am currently trying to solve.

So the descent stage phase of Apollo 5 is now mostly solved.  Excited!
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #764 on: June 02, 2017, 11:26:18 AM »

I'm synced with the main 2016 branch, though. Just did a fetch a second ago. So IDK if there's something missing from the trunk build or I have to recompile...
Logged
Pages: 1 ... 49 50 [51] 52 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!