144 [00:00:00] ### Log session started ###
20 [01:34:06] pg_ [~pg@ACaen-654-1-86-243.w81-48.abo.wanadoo.fr] has joined #nassp
34 [01:37:08] orbi4 [~orbi4@ACaen-654-1-29-20.w83-115.abo.wanadoo.fr] has quit IRC: Ping timeout: 260 seconds
34 [01:37:08] pg [~pg@ACaen-654-1-29-20.w83-115.abo.wanadoo.fr] has quit IRC: Ping timeout: 260 seconds
25 [02:07:08] <thewonderidiot> hmmm
25 [02:07:23] <thewonderidiot> 16 is not the fixed bank indicated there
25 [02:07:40] <thewonderidiot> it's effectively shifted up by one, so that's really fixed bank 7 that the alarm occurred in
25 [02:07:57] <thewonderidiot> 07,2000 is where the TC ALARM in FAKESTRT is
25 [02:07:59] <thewonderidiot> so that's not helpful
25 [02:08:09] <thewonderidiot> it would be much more useful to know where the CCSHOLE was hit
25 [02:08:15] <thewonderidiot> because that is a really weird thing to hit
25 [02:10:03] <thewonderidiot> it would probably be useful to try again except with full restartability enabled, so we can avoid the dumb fakestrt thing
25 [02:11:15] <thewonderidiot> oh you guys already got to that
25 [02:11:25] <thewonderidiot> lol
25 [02:15:01] <thewonderidiot> so yeah, FAKESTRT can only be entered when bit 12 of FLGWRD1 is 0
25 [02:17:34] <thewonderidiot> it looks like Sunburst *can* force a FAKESTRT if it really strongly wants to via ABORT2
25 [02:17:45] <thewonderidiot> by resetting that flag itself
25 [02:17:52] <thewonderidiot> but if it does that it WHIMPERs to get the restart
25 [02:17:58] <thewonderidiot> did the RESTART light come on or just PROG?
24 [03:11:00] <@Thymo> I think he had a full restart. FAKESTRT is called by GOPROG anyway.
24 [03:11:50] <@Thymo> Sunburst is doing a lot of stuff different. I don't understand it yet.
24 [03:16:55] <@Thymo> Why is BBANK shifted up?
144 [03:17:38] ### Log session terminated ###
144 [12:43:59] ### Log session started ###
20 [12:43:59] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
23 [12:43:59] Channel topic is: Welcome to #nassp! Wiki: http://nassp.sf.net Forum: http://www.ibiblio.org/mscorbit/mscforum GitHub: https://github.com/dseagrav/NASSP
23 [12:43:59] Topic was set by Thymo!~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl on Wed Feb 22 16:30:28 2017
25 [12:43:59] <***> Buffer Playback...
2 [12:43:59] <thewonderidiot> [03:40:48] Thymo: the FB bits are as "left" or high as they can possibly be in the 15-bit word
25 [12:43:59] <thewonderidiot> [03:41:02] since FB is five bits wide, it occupies the most significant five bits
25 [12:43:59] <thewonderidiot> [03:41:58] so bank 7 would be 00111 in binary, but end up in the word like 00111xxxxxxxxxx
25 [12:43:59] <thewonderidiot> [03:42:16] encoding that as octal you end up with either 16xxx or 17xxx
25 [12:43:59] <thewonderidiot> [03:42:40] you can recover the actual FB value by just shifting the first two octal digits right once
25 [12:43:59] <thewonderidiot> [03:42:54] 016 >> 1 == 07
25 [12:43:59] <thewonderidiot> [03:43:29] and yeah, I spent a bit of time looking at it over dinner
25 [12:43:59] <thewonderidiot> [03:43:39] Niklas may have discovered a sort of design flaw in CCSHOLE
25 [12:43:59] <thewonderidiot> [03:44:24] just to narrate exactly what happened:
25 [12:43:59] <thewonderidiot> [03:44:28] he triggered a CCSHOLE
25 [12:43:59] <thewonderidiot> [03:44:45] that stores the address of the problem in ALMCADR, then heads to ABORT2 with the alarm code 1103
25 [12:43:59] <thewonderidiot> [03:45:22] ABORT2 loads the 1103 and TCs to BORTENT
25 [12:43:59] <thewonderidiot> [03:45:29] then program alarm things happen
25 [12:43:59] <thewonderidiot> [03:46:03] actually before program alarm things happen, Q is stored in RUPTREG4
25 [12:43:59] <thewonderidiot> [03:46:25] so RUPTREG4 is now pointing at the constant OCT40400 after the end of ABORT2
25 [12:44:00] <thewonderidiot> [03:46:37] so program alarm things happen, and it gets to MULTEXIT
25 [12:44:00] <thewonderidiot> [03:46:59] which loads RUPTREG4 and indexes it onto a TC 1
25 [12:44:00] <thewonderidiot> [03:47:15] so control is transferred to the position right after OCT40400
25 [12:44:00] <thewonderidiot> [03:47:37] which forcibly resets the restartability flag and WHIMPERs
25 [12:44:00] <thewonderidiot> [03:47:57] so then the computer restarts, it goes into GOPROG, and seemingly unavoidably runs FAKESTRT
25 [12:44:00] <thewonderidiot> [03:48:09] which immediately calls ALARM
25 [12:44:00] <thewonderidiot> [03:48:39] which then immediately stores the location of that call to ALARM in ALMCADR, clobbering the address of the CCSHOLE
25 [12:44:00] <thewonderidiot> [03:48:54] ....I'm not entirely sure it's possible to recover that CCSHOLE address
25 [12:44:00] <thewonderidiot> [03:49:13] unless we can somehow make the FAKESTRT not happen
25 [12:44:00] <thewonderidiot> [03:51:53] maybe if we send it through DOFSTART, it won't hit the call to FAKESTRT
25 [12:44:00] <thewonderidiot> [03:52:01] it will be incredibly destructive to erasable memory though
25 [12:44:00] <thewonderidiot> [03:52:16] but this is just a simulator so I think we can accept that :)
25 [12:44:00] <thewonderidiot> [03:52:50] okay, possible procedure to prevent FAKESTRT
25 [12:44:00] <thewonderidiot> [03:52:59] stick a 1 into ERESTORE, which is at 1353
25 [12:44:00] <thewonderidiot> [03:53:13] that tricks Sunburst into thinking a failure happened during the erasable memory test
25 [12:44:00] <thewonderidiot> [03:53:25] and so it doubts erasable and clears most of the important thing
25 [12:44:00] <thewonderidiot> [03:53:40] but I *think* avoids touching ALMCADR, and skips the call to FAKESTRT
25 [12:44:00] <thewonderidiot> [03:56:02] gotta run right now but I'll try that a bit later and report back if it should work
25 [12:44:00] <thewonderidiot> [05:43:55] okay, I just tried it out, and the procedure is confirmed
25 [12:44:00] <thewonderidiot> [05:45:59] apparently just doing V30E with blank erasable memory triggers a CCSHOLE, which is really convenient
25 [12:44:00] <thewonderidiot> [05:46:35] normally when I do that, I get a restart and V15 N50 shows 01103, 00316, 41110
25 [12:44:00] <thewonderidiot> [05:47:06] so like expected, a CCSHOLE followed by a FAKESTRT
25 [12:44:00] <thewonderidiot> [05:47:25] if I then do V01N01E 1353E 1E
25 [12:44:00] <thewonderidiot> [05:47:44] sorry
25 [12:44:00] <thewonderidiot> [05:47:48] V21N01E 1353E 1E
25 [12:44:00] <thewonderidiot> [05:48:17] then I do V30E again to trigger the same CCSHOLE
25 [12:44:00] <thewonderidiot> [05:49:00] V15 N50 now shows 01103, 01103, 00000
25 [12:44:00] <thewonderidiot> [05:49:04] no 316 alarm
25 [12:44:00] <thewonderidiot> [05:49:51] and N31 shows 03134, 02000, 00000
25 [12:44:00] <thewonderidiot> [05:50:11] which would (hopefully) indicate a CCSHOLE in 01,3133
25 [12:44:00] <thewonderidiot> [05:50:32] and indeed, that is a TC CCSHOLE
25 [12:44:00] <thewonderidiot> [05:50:37] so that procedure should work
25 [12:44:00] <thewonderidiot> [05:50:42] it'll nuke erasable memory
25 [12:44:00] <thewonderidiot> [05:50:45] but eh :D
2 [12:44:00] <thewonderidiot> [06:03:43] Thymo: please pass my monologue on to Niklas tomorrow morning!
25 [12:44:00] <***> Playback Complete.
51 [12:44:29] niven.freenode.net [*@*] has set channel mode +cgnt
62 [12:44:29] Channel was created at Sun Jan 8 21:49:15 2017
15 [12:44:37] Channel synchronized in 37.948 seconds
24 [12:44:42] <@Thymo> Hey
25 [12:45:58] <@indy91> hey
25 [12:46:58] <@indy91> Did you try my Sunburst scenario yet? Did you also get the PIPA fail alarm like eddievhfan1984?
24 [12:48:52] <@Thymo> I didn't. Mike came up with a procedure. Are you ready to receive a monologue?
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:40:48] Thymo: the FB bits are as "left" or high as they can possibly be in the 15-bit word
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:41:02] since FB is five bits wide, it occupies the most significant five bits
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:41:58] so bank 7 would be 00111 in binary, but end up in the word like 00111xxxxxxxxxx
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:42:16] encoding that as octal you end up with either 16xxx or 17xxx
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:42:40] you can recover the actual FB value by just shifting the first two octal digits right once
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:42:54] 016 >> 1 == 07
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:43:29] and yeah, I spent a bit of time looking at it over dinner
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:43:39] Niklas may have discovered a sort of design flaw in CCSHOLE
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:44:24] just to narrate exactly what happened:
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:44:28] he triggered a CCSHOLE
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:44:45] that stores the address of the problem in ALMCADR, then heads to ABORT2 with the alarm code 1103
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:45:22] ABORT2 loads the 1103 and TCs to BORTENT
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:45:29] then program alarm things happen
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:46:03] actually before program alarm things happen, Q is stored in RUPTREG4
24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:46:25] so RUPTREG4 is now pointing at the constant OCT40400 after the end of ABORT2
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:46:37] so program alarm things happen, and it gets to MULTEXIT
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:46:59] which loads RUPTREG4 and indexes it onto a TC 1
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:47:15] so control is transferred to the position right after OCT40400
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:47:37] which forcibly resets the restartability flag and WHIMPERs
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:47:57] so then the computer restarts, it goes into GOPROG, and seemingly unavoidably runs FAKESTRT
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:48:09] which immediately calls ALARM
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:48:39] which then immediately stores the location of that call to ALARM in ALMCADR, clobbering the address of the CCSHOLE
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:48:54] ....I'm not entirely sure it's possible to recover that CCSHOLE address
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:49:13] unless we can somehow make the FAKESTRT not happen
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:51:53] maybe if we send it through DOFSTART, it won't hit the call to FAKESTRT
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:52:01] it will be incredibly destructive to erasable memory though
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:52:16] but this is just a simulator so I think we can accept that :)
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:52:50] okay, possible procedure to prevent FAKESTRT
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:52:59] stick a 1 into ERESTORE, which is at 1353
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:53:13] that tricks Sunburst into thinking a failure happened during the erasable memory test
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:53:25] and so it doubts erasable and clears most of the important thing
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:53:40] but I *think* avoids touching ALMCADR, and skips the call to FAKESTRT
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:56:02] gotta run right now but I'll try that a bit later and report back if it should work
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:43:55] okay, I just tried it out, and the procedure is confirmed
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:45:59] apparently just doing V30E with blank erasable memory triggers a CCSHOLE, which is really convenient
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:46:35] normally when I do that, I get a restart and V15 N50 shows 01103, 00316, 41110
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:06] so like expected, a CCSHOLE followed by a FAKESTRT
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:25] if I then do V01N01E 1353E 1E
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:44] sorry
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:48] V21N01E 1353E 1E
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:48:17] then I do V30E again to trigger the same CCSHOLE
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:49:00] V15 N50 now shows 01103, 01103, 00000
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:49:04] no 316 alarm
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:49:51] and N31 shows 03134, 02000, 00000
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:11] which would (hopefully) indicate a CCSHOLE in 01,3133
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:32] and indeed, that is a TC CCSHOLE
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:37] so that procedure should work
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:42] it'll nuke erasable memory
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:45] but eh :D
24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [06:03:43] Thymo: please pass my monologue on to Niklas tomorrow morning!
25 [12:50:16] <@indy91> woooow
24 [12:50:16] <@Thymo> So we can find out where you got that CCSHOLE but you will nuke erasable memory in the process.
25 [12:50:31] <@indy91> no problem, I can also reload the scenario :D
25 [12:50:34] <@indy91> always*
24 [12:51:36] <@Thymo> So make sure you do V21N01E 1353E 1E before the restart and then we'll have the debug info.
25 [12:53:20] <@indy91> Do I have to do the procedure as close as possible to the restart?
25 [12:53:59] <@indy91> Or does ERESTORE only do something during a restart?
24 [12:54:13] <@Thymo> Don't think so since you set a flag that the erasable memory self test failed. I'll take a look.
24 [12:54:54] <@Thymo> We basically force the AGC to do a full restart because memory failed which bypasses FAKESTRT.
24 [12:55:07] <@Thymo> So we keep the CADR of the CCSHOLE
24 [12:56:04] <@Thymo> thewonderidiot: Remind me about yaDSKY when you get on. I keep forgetting to mention it.
25 [13:00:11] <@indy91> just did the procedure
25 [13:00:11] <@indy91> hope it gives nice alarm data now
25 [13:00:11] <@indy91> 01103, 00000, 00000
25 [13:00:11] <@indy91> 02422, 34006, 00000
25 [13:00:11] <@indy91> awesome
25 [13:00:11] <@indy91> now let's find where that is :D
25 [13:06:23] <@indy91> still don't know how to convert that into bank...
24 [13:06:38] <@Thymo> I think it's in CKTRMCTR in P-AXIS_REACTION_CONTROL_SYSTEM_AUTOPILOT.agc
24 [13:07:01] <@Thymo> Bank 16, return adres 2422
25 [13:07:06] <@indy91> looking at that right now, too
25 [13:07:28] <@indy91> so something with the gimbal drive
24 [13:07:44] <@Thymo> COUNTDOWN FOR FORCED GTS ENTRY.
24 [13:08:22] <@Thymo> Erasable bank also checks out.
24 [13:09:13] <@Thymo> What's GTS?
25 [13:12:48] <@indy91> Gimbal Trim System or something like that
25 [13:13:50] <@indy91> yep
24 [13:14:56] <@Thymo> It happens right at ignition doesn't it?
25 [13:15:08] <@indy91> yep
25 [13:15:17] <@indy91> for a split second there is an engine on signal
24 [13:15:28] <@Thymo> Is FORCETRM a padload?
25 [13:15:29] <@indy91> So I guess it happens when it wants to start using the GTS
24 [13:15:48] <@Thymo> Address 1746 ebank 6
25 [13:16:39] <@indy91> FORCETRM
25 [13:17:32] <@indy91> nothing is loaded there
25 [13:17:32] <@indy91> in the padload
25 [13:17:53] <@indy91> But most addresses around it are used in the padload
24 [13:17:54] <@Thymo> I think that oone became invalid somehow
25 [13:18:16] <@indy91> And it says: "PARAMETERS IN ERASABLE LOAD:"
25 [13:18:36] <@indy91> So I guess the problem is that a padloaded value is missing in FORCETRM?
25 [13:19:08] <@indy91> CCSHOLE happens because it's +0
25 [13:19:15] <@indy91> Which is of course the case if nothing was loaded
25 [13:19:18] <@indy91> that's gotta be it
24 [13:19:42] <@Thymo> Yes. If it's not padloaded it will be +0. The CCSHOLE only triggers on +0
25 [13:19:47] <@indy91> yep
25 [13:19:54] <@indy91> ok
25 [13:19:57] <@indy91> what does it want there :D
25 [13:21:54] <@indy91> maybe I find something in the Sundance GSOP
25 [13:22:04] <@indy91> But it's likely Sunburst specific
24 [13:22:59] <@Thymo> I think -0 will do. That starts smartjob.
25 [13:23:50] <@indy91> is it EMEM3346?
24 [13:24:00] <@Thymo> SMARTJOB IS A DUMMYJOB-LIKE FUNCTION DESIGNED TO ABSORB IDLE TIME.  IT CAUSES THE COMPUTER-ACTIVITY LAMP TO REMAIN ON, AND PREVENTS THE EXISTENCE OF A JOB SLEEPING IN TH ELOWEST NUMBERED CORE SET.  IT IS PREVENTED FROM STARTING, OR MADE TO TERMINATE IF ALREADY RUNNING, BY MAKING SMARTFLG CONTAIN ANY NEGATIVE VALUE OR ZERO, OR BY MAKING SMODE (THE SELFCHECK CONTROL REGISTER) UNEQUAL TO +0.
25 [13:24:58] <@indy91> So I will try EMEM3346 77777
24 [13:25:21] <@Thymo> Maybe. Do you have a padload for DRIVELIM?
24 [13:25:34] <@Thymo> One below that.
25 [13:25:56] <@indy91> nope
25 [13:26:06] <@indy91> I only have COUNTBOX, a few above
24 [13:26:29] <@Thymo> COUNTBOX +3
25 [13:26:31] <@indy91> I think I might be a missing a few numbers there
24 [13:27:36] <@Thymo> You don't need to load the two above COUNTBOX. TRIMCNTR will get loaded with FORCETRM and GTSMNITR needs to be +0 (which is what the erasable memory gets initialized too).
25 [13:28:50] <@indy91> then I'll only try the -0 in 3346 first
25 [13:29:49] <@indy91> surely that would give new program alarms
25 [13:30:46] <@indy91> no alarm!
25 [13:30:56] <@indy91> at 10% throttle
25 [13:31:25] <@indy91> 100%
25 [13:31:26] <@indy91> cutoff
25 [13:31:37] <@indy91> perfect orbit
25 [13:31:42] <@indy91> exactly at perigee
25 [13:31:48] <@indy91> so flight path angle 0°
25 [13:31:56] <@indy91> which is exactly what the SCOT said it should be
25 [13:32:25] <@indy91> orbit is 112x186
25 [13:33:36] <@indy91> I have to try this again. There currently is a bug in the DPS control logic that makes it cycle on and off
25 [13:33:49] <@indy91> But I think everything is working exactly as it should
25 [13:35:09] <@indy91> Apollo 5 can continue!
25 [13:35:16] <@indy91> The next DPS burn is the really exciting one
25 [13:35:28] <@indy91> powered descent simulation, with braking and approach phase
24 [13:35:32] <@Thymo> Woo!
25 [13:35:56] <@indy91> simply loading -0 instead of +0 fixed it :D
25 [13:36:11] <@indy91> what a great computer you are, AGC
25 [13:37:24] <@indy91> Interestingly, after cutoff the LGC hasn't commanded throttle down yet
25 [13:37:37] <@indy91> Usually the LGC will command maximum negative throttle commands
25 [13:37:42] <@indy91> after cutoff
25 [13:38:08] <@indy91> But Sunburst also doesn't always send an "Engine Off" signal, so, just more weirdness
25 [13:39:12] <@indy91> oh, and planned orbit is 116x179 after the DPS burn
25 [13:39:14] <@indy91> not bad
25 [13:39:37] <@indy91> And I think it might have been even better without the DPS bug
25 [13:39:43] <@indy91> fixed that one now
25 [13:43:30] <@indy91> the only reason the perigee is off is because the burn happens at 112NM altitude
25 [13:43:42] <@indy91> TIG is fixed
25 [13:43:58] <@indy91> and I guess the insertion orbit was slightly off
25 [13:44:05] <@indy91> no big deal
25 [13:45:07] <@indy91> oh, and it's missing tailoff thrust
25 [13:45:12] <@indy91> I should change those padloads
25 [13:45:23] <@indy91> 112x176 now
25 [13:45:34] <@indy91> would have been perfect with thrust tailoff
25 [13:46:06] <@indy91> now waiting for P00, saving and then checking all the padloaded values for the long DPS burn
25 [13:50:03] <@indy91> Sunburst just went further into the flight than Apollo 5 ever did!
24 [13:51:14] <@Thymo> Awesome!
24 [13:51:46] <@Thymo> When you finish this it will be a nice item for the Virtual AGC mailing list.
25 [13:51:51] <@indy91> oh yes
25 [13:52:06] <@indy91> The second DPS burn is 12 minutes long. Then it will randomly throttle around
25 [13:52:15] <@indy91> and then fire in the hole - abort test
25 [13:52:29] <@indy91> and then an APS burn, of course
25 [13:52:44] <@indy91> a very short one, just after the abort
25 [13:52:53] <@indy91> abort staging*
25 [13:53:46] <@indy91> so that is the PDI simulation
25 [13:53:59] <@indy91> mostly out-of-plane, I think
25 [13:56:06] <@indy91> save at T+4:33:00
25 [13:56:10] <@indy91> 30*
25 [13:56:19] <@indy91> and in 3 minutes the fun should begin
25 [13:56:27] <@indy91> I expect new program alarms, of course :D
25 [13:56:54] <@indy91> oh noo
25 [13:56:57] <@indy91> sunset
25 [13:57:03] <@indy91> burn will happen in the dark
25 [13:57:13] <@indy91> Program 32!
25 [13:57:19] <@indy91> restart
25 [13:57:39] <@indy91> I think it might be stuck
25 [13:57:51] <@indy91> COMP ACTY light stays on
25 [13:57:59] <@indy91> it displayed the V15 N50, but it's all 0
25 [13:58:38] <@indy91> ok, new alarms
25 [13:58:49] <@indy91> 1202, 316 and 41110
25 [13:59:04] <@indy91> V15 N31
25 [13:59:14] <@indy91> 02340, 02003
24 [14:01:31] <@Thymo> Fun.
24 [14:02:14] <@Thymo> The last alarm is 1110 Restart but no groups active
24 [14:03:17] <@Thymo> V01N10E 77E
24 [14:03:33] <@Thymo> Check the restart monitor
24 [14:04:01] <@Thymo> The groundstation program would be really handy for this.
25 [14:08:00] <@indy91> The only realistic method if interacting with LM-1 :D
25 [14:08:11] <@indy91> of*
25 [14:13:18] <@indy91> so, according to the SCOT some sort of ignition algorithm is running when P32 starts
25 [14:13:31] <@indy91> so that's probably where it already fails
25 [14:17:14] <@indy91> https://www.ibiblio.org/apollo/listings/Sunburst120/MISSION_PHASE_11-DPS2_FITH_APS1.agc.html
25 [14:17:14] <Guenter> [ Assembly listing generated by yaYUL ] - www.ibiblio.org
25 [14:17:29] <@indy91> does that artificially cause a restart right at the beginning?
25 [14:19:04] <@indy91> ok, I think I caused the 1202 alarm
25 [14:19:12] <@indy91> by typing stuff into the DSKY
25 [14:19:18] <@indy91> now I get a 410 alarm instead
24 [14:19:27] <@Thymo> The SETRSTRT flag? That enables restartability.
25 [14:19:32] <@indy91> oh, ok
25 [14:19:46] <@indy91> first a restart with no program alarm code in V15 N50 and then 410
25 [14:20:20] <@indy91> but it didn't go to P00 yet
24 [14:20:35] <@Thymo> 00410 OVERFLOW PRIOR TO OR DURING COMPUTATION OF ACS OR AFCS (MP 11)
25 [14:20:57] <@indy91> yeah, I am in MP11
25 [14:21:21] <@indy91> I'll let it running until in goes to P00
25 [14:21:29] <@indy91> should switch to P42
25 [14:21:33] <@indy91> but that will probably fail
24 [14:21:34] <@Thymo> How did you trigger a 1202?
25 [14:22:45] <@indy91> by typing V15 N31, I think
25 [14:23:12] <@indy91> yeah, it's stuck. There should have been ignition by now.
24 [14:23:15] <@Thymo> Possible if the AGC was under heavy load.
25 [14:23:19] <@indy91> yep
25 [14:23:30] <@indy91> it's still on full comp activity
25 [14:23:50] <@indy91> yeah, stuck
25 [14:23:59] <@indy91> as soon as I type anything nothing happens at first
25 [14:24:02] <@indy91> and then it goes to P00
24 [14:24:18] <@Thymo> Comp activity is a light that the computer arbitrarily turns on and off. It might simply be glitched out.
25 [14:24:27] <@indy91> could be
25 [14:24:36] <@indy91> it was on for 99% of the time
25 [14:24:39] <@indy91> but not 100%
25 [14:24:54] <@indy91> Where in the code is the 410 alarm?
24 [14:25:08] <@Thymo> Then it's probably stuck in some computation.
25 [14:25:19] <@indy91> yeah
25 [14:25:30] <@indy91> I would be some more missing padload stuff
25 [14:25:40] <@indy91> guess*
25 [14:26:32] <@indy91> ACS or AFCS are the desired acceleration vector, I think
25 [14:28:07] <@indy91> Could of course also be a wrong padload
25 [14:28:15] <@indy91> the MP11 targets I used are from the SCOT
25 [14:28:24] <@indy91> which is not for the correct launch day
25 [14:29:03] <@indy91> and it's totally different in the AS-206 document as compared with the SCOT
25 [14:29:15] <@indy91> So, this might be launch time dependant
25 [14:29:48] <@indy91> or wait a minute...
25 [14:29:58] <@indy91> I think the SCOT values are in the wrong coordinate system
25 [14:30:05] <@indy91> So I'll try the one from AS-206
25 [14:30:10] <@indy91> one*
25 [14:32:36] <@indy91> yeah, SCOT has Earth Centered Inertial (ECI) coordinates for the MP11 target vector
24 [14:32:37] <@Thymo> The AGC went into MULTFAIL. You had more alarms than those 3.
25 [14:32:57] <@indy91> but the padload should be IMU coordinates
25 [14:33:16] <@indy91> I think I caused almost all alarms, except for 410
25 [14:33:21] <@indy91> and the first restart
25 [14:33:48] <@indy91> 410 is the only alarm that was there before I started using the DSKY
24 [14:33:49] <@Thymo> Yeah. Can you check the restart monitor?
25 [14:34:25] <@indy91> I'll try the AS-206 padload target vector first
25 [14:35:00] <@indy91> the calculated orbital plane was probably so much off, that it would have to use a huge acceleration to achieve that
25 [14:35:09] <@indy91> no restart!
25 [14:35:22] <@indy91> and no alarms... yet
25 [14:35:33] <@indy91> COMP ACTY light not stuck anymore!
25 [14:35:44] <@indy91> it stayed on for a while, but I think it finished calculating
25 [14:35:55] <@indy91> this might work!
25 [14:38:03] <@indy91> P42!
25 [14:38:25] <@indy91> I wonder if the throttle at 100% was also something broken by my control logic update...
25 [14:38:34] <@indy91> ignition
25 [14:39:30] <@indy91> looks good
25 [14:39:40] <@indy91> but I doubt it will properly do the throttle test
25 [14:39:46] <@indy91> we'll see
25 [14:39:57] <@indy91> first 10 more minutes of the burn
24 [14:40:40] <@Thymo> That's a long burn.
25 [14:40:48] <@indy91> yeah
25 [14:41:26] <@indy91> I guess the test is a late PDI abort
25 [14:41:27] <@indy91> very late
25 [14:42:09] <@indy91> rip
25 [14:42:12] <@indy91> gimbal lock :D
24 [14:42:34] <@Thymo> Haha
25 [14:42:35] <@indy91> I think it might have had some sort of control loss
25 [14:42:45] <@indy91> about 4 minutes into the burn
25 [14:43:30] <@indy91> I'll have to try that again, to see if it first had gimbal lock, or first control loss
25 [14:43:35] <@indy91> I think it was control loss first
25 [14:43:44] <@indy91> in any case, the target vector might still be bad
25 [14:43:53] <@indy91> causing it to be closer to gimbal lock than necessary
25 [14:56:09] <@indy91> next try
25 [14:56:20] <@indy91> I have edited the scenario so that it starts at 10% throttle
25 [15:00:46] <@indy91> hmm
25 [15:00:53] <@indy91> at some point it stops issuing RCS commands
25 [15:00:58] <@indy91> and then it starts spinning
25 [15:02:31] <@indy91> it did go to the random throttle command sequence though
25 [15:04:16] <@indy91> hmm
25 [15:04:24] <@indy91> there is an interesting padload related to that
25 [15:04:35] <@indy91> DAPOFFDT, Time from TIG+26 in MP11 to DAP Turn-Off
25 [15:04:42] <@indy91> 162 seconds
25 [15:07:15] <@indy91> "DAP is scheduled to be turned off for 4 sec in MP11 burn by changing fresh start initialization"
24 [15:07:27] <@Thymo> Why would anyone want to do that?
25 [15:07:34] <@indy91> no idea
25 [15:07:45] <@indy91> source code says "set to 0 or negative to inhibit DAP turn-off"
25 [15:07:48] <@indy91> I'll try that
25 [15:08:25] <@indy91> and it didn't turn it off for 4 seconds
25 [15:08:32] <@indy91> seemed like it never issued any commands anymore
25 [15:09:18] <@indy91> after the random throttle sequence it goes to 100% again
25 [15:09:24] <@indy91> and then I have to do the abort staging
24 [15:09:40] <@Thymo> It starts a special cdu downlink
25 [15:09:55] <@indy91> some test then
24 [15:10:14] <@Thymo> Which is supposed to turn it on again after it's done.
25 [15:10:21] <@indy91> hmm
25 [15:10:24] <@indy91> weird
25 [15:10:34] <@indy91> might be a broken feature, who knows
25 [15:10:58] <@indy91> I'll have to find a better document with planned Apollo 5 tests
24 [15:13:19] <@Thymo> It looks like they downlink a snapshot of the cdu angles during the burn. After that the DAP is supposed to come on again.
24 [15:17:07] <@Thymo> That that DAP inhibit work?
25 [15:17:15] <@indy91> still testing
25 [15:17:23] <@indy91> haven't reached that time yet
25 [15:17:37] <@indy91> but 162 + 26 seconds after ignition seem like the time when it happened
25 [15:20:06] <@indy91> seems like the DAP stayed working
25 [15:20:08] <@indy91> lots of RCS firing
25 [15:23:03] <@indy91> hmm
25 [15:23:11] <@indy91> it shouldn't stay at 100%
25 [15:23:20] <@indy91> it should do some throttle recovery for a few minutes
25 [15:23:26] <@indy91> oh
25 [15:23:27] <@indy91> P43!
25 [15:23:31] <@indy91> whatever that one does, lol
25 [15:23:52] <@indy91> approach phase
25 [15:23:56] <@indy91> but throttle is at 100%
25 [15:24:07] <@indy91> it was just at a lower setting for a few seconds
25 [15:24:39] <@indy91> oh fun
25 [15:24:41] <@indy91> another 410 alarm
25 [15:25:12] <@indy91> oops, did the abort stage too early
25 [15:25:23] <@indy91> It went into P44, where I thought I had to do staging
25 [15:25:31] <@indy91> P44 is "DPS2 Burn - Random Throttle" :D
10 [16:20:52] Connection to server lost
42 [16:21:03] You have set user mode +Zi
86 [16:21:03] [Entering away status]: You have been marked as being away
144 [16:21:04] ### Log session terminated ###
144 [16:21:04] ### Log session started ###
20 [16:21:04] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
23 [16:21:04] Channel topic is: Welcome to #nassp! Wiki: http://nassp.sf.net Forum: http://www.ibiblio.org/mscorbit/mscforum GitHub: https://github.com/dseagrav/NASSP
23 [16:21:04] Topic was set by Thymo!~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl on Wed Feb 22 16:30:28 2017
57 [16:21:57] indy91 is indy91!~indy91@2a02:8108:8b40:3aa8:e95b:c8ea:61be:23e4
57 [16:21:57] indy91's real name: realname
58 [16:21:57] indy91's channels: @#nassp
60 [16:21:57] indy91's server: leguin.freenode.net - Umeå, SE, EU
61 [16:21:57] indy91's info: is using a secure connection
59 [16:21:57] indy91's idle time: 0d 0h 55m 55s
59 [16:21:57] indy91's signon time: Fri Jun 2 11:38:06 2017
61 [16:21:57] indy91 is authenticated as indy91
61 [16:21:57] indy91 WHOIS info from leguin.freenode.net
51 [16:21:57] niven.freenode.net [*@*] has set channel mode +cgnt
62 [16:21:57] Channel was created at Sun Jan 8 21:49:15 2017
15 [16:21:57] Channel synchronized in 53.43 seconds
10 [16:53:38] Connection to server lost
42 [16:53:48] You have set user mode +Zi
86 [16:53:48] [Entering away status]: You have been marked as being away
144 [16:53:48] ### Log session terminated ###
144 [16:53:48] ### Log session started ###
20 [16:53:48] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
23 [16:53:48] Channel topic is: Welcome to #nassp! Wiki: http://nassp.sf.net Forum: http://www.ibiblio.org/mscorbit/mscforum GitHub: https://github.com/dseagrav/NASSP
23 [16:53:48] Topic was set by Thymo!~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl on Wed Feb 22 16:30:28 2017
51 [16:54:25] niven.freenode.net [*@*] has set channel mode +cgnt
62 [16:54:25] Channel was created at Sun Jan 8 21:49:15 2017
15 [16:54:28] Channel synchronized in 39.954 seconds
25 [16:55:25] <@indy91> The LM I am using is more than 1000 kg too heavy
25 [16:55:44] <@indy91> must be the legs
24 [17:04:18] <@Thymo> Lost connection. Did you say anything before "The LM I am using is more than 1000 kg too heavy"?
25 [17:05:50] <@indy91> not for the last 90 minutes
25 [17:06:38] <@indy91> the 410 alarm could be mass related. it doesn't achieve as much DV change as necessary for the planned profile during the burn
25 [17:06:57] <@indy91> that's why it doesn't really throttle down
25 [17:07:36] <@indy91> throttle down!
25 [17:07:43] <@indy91> just like during a lunar landing
25 [17:08:35] <@indy91> 1405, 315 alarm
25 [17:08:51] <@indy91> it controls terribly at low mass
25 [17:09:17] <@indy91> I think I missed the staging time
25 [17:10:03] <@indy91> But all in all this was a much better attempt
25 [17:10:35] <@indy91> maybe there is a mass difference between what the LGC thinks and actual mass
25 [17:12:37] <@indy91> LGC mass is 6245 kg, actual mass 6000 kg
25 [17:13:31] <@indy91> Might also be a difference in DPS mass flow rate
25 [17:13:44] <@indy91> I'll give it 200kg more and will try to remember to do staging
24 [17:14:14] <@Thymo> 1405 DV ALARM.  ENGINE ON BUT NO THRUST. 315 FORGETIT
25 [17:14:37] <@indy91> might be because it's expecting APS thrust
25 [17:14:40] <@indy91> yeah
25 [17:15:36] <@indy91> I didn't know that until a few days ago, but the LGC actually sends commands to the Programer
25 [17:15:47] <@indy91> stuff like staging, RCS Pressurization etc.
25 [17:16:21] <@indy91> I always thought it was the other way around. Programer sends commands to LGC and all other systems
25 [17:16:41] <@indy91> But Sunburst is really more in control of the LM than any other LGC version
24 [17:18:43] <@Thymo> How does it send the commands? Through input channels?
24 [17:18:49] <@Thymo> s/input/output
2 [17:18:49] <Guenter> Thymo meant to say: How does it send the commands? Through output channels?
25 [17:19:40] <@indy91> I am not sure yet
25 [17:19:45] <@indy91> there is a LMP routine
25 [17:19:48] <@indy91> LM Programer
25 [17:19:57] <@indy91> with some sort of code
25 [17:20:10] <@indy91> https://www.ibiblio.org/apollo/listings/Sunburst120/LMP_COMMAND_ROUTINES.agc.html
25 [17:20:10] <Guenter> [ Assembly listing generated by yaYUL ] - www.ibiblio.org
25 [17:20:31] <@indy91> THE PROPER DECIMAL CODE IS ENTERED INTO A TABLE AND FROM THENCE TO CHANNEL 10 VIA T4RUPT AND ARE INCLUDED IN
25 [17:20:35] <@indy91> THE DOWNLINK.
25 [17:23:42] <@indy91> Systems Handbook has a list of commands
25 [17:23:56] <@indy91> seems pretty possible to create the LM Programer
25 [17:25:43] <@indy91> THRUST AT MAX FOR 1 MORE SEC AND ABORT
25 [17:25:49] <@indy91> that's what I have to look for
25 [17:26:01] <@indy91> random throttle sequence, full throttle, press abort stage
25 [17:27:32] <@indy91> during the burn the LM is directly over Houston
25 [17:29:36] <@indy91> throttle down and P43
25 [17:29:42] <@indy91> don't miss it this time :D
25 [17:34:23] <@indy91> didn't miss it, but it never started P74 for the APS burn
25 [17:34:46] <@indy91> it should monitor the abort stage bit and/or the stage bit
25 [17:37:04] <@indy91> It looks for the Stage Verify bit, channel 30 bit 2
25 [17:37:25] <@indy91> that should be set at staging
25 [17:38:49] <@indy91> but everything until then worked exactly as per SCOT
25 [17:42:41] <@indy91> in any case, I am pretty sure the MP11 target vector is working
2 [18:01:42] <@indy91> Thymo, can you check for me a few things in the code?
25 [18:01:46] <@indy91> 1. when does it start/stop monitoring the staging bit.
25 [18:01:55] <@indy91> 2. Is it looking for the inverted state, like usual for input bits.
25 [18:02:17] <@indy91> I had a 3rd question, but I forgot :D
24 [18:04:11] <@Thymo> Still during MP11?
25 [18:04:35] <@indy91> yeah
25 [18:04:36] <@indy91> all in here
25 [18:04:37] <@indy91> https://www.ibiblio.org/apollo/listings/Sunburst120/MISSION_PHASE_11-DPS2_FITH_APS1.agc.html#41424D4F4E
25 [18:04:38] <Guenter> [ Assembly listing generated by yaYUL ] - www.ibiblio.org
25 [18:05:08] <@indy91> Maybe the timing of the staging is more critical. After all the LGC commands it itself
24 [18:05:30] <@Thymo> It does a bitwise AND on channel 30 bit 2.
24 [18:06:37] <@Thymo> And it jumps to FITHGCMD if it's zero.
24 [18:06:42] <@Thymo> So it is inverted.
25 [18:07:15] <@indy91> right
25 [18:07:21] <@indy91> When does it start looking for it?
25 [18:07:24] <@indy91> in P44 or earlier?
24 [18:07:40] <@Thymo> TIG-7.5
24 [18:07:54] <@Thymo> At the same time as the ullage.
25 [18:08:14] <@indy91> wow, so very early
24 [18:08:16] <@Thymo> After that every .5 seconds until it detects staging.
25 [18:08:59] <@indy91> the bit is set in the lemmesh.cpp functions
25 [18:09:22] <@indy91> So it would be weird if it isn't set
25 [18:10:13] <@indy91> Also, what happens if it never finds the bit? Last time I had some program alarms, I think.
24 [18:14:02] <@Thymo> Actually I might be wrong. ABMON is the abort monitor that checks for an abort initiated from the ground.
24 [18:15:48] <@Thymo> What alarm did you get?
24 [18:19:36] <@Thymo> Looks like nothing specifically happens if the abort fails. The AGC will probably crash after the APS isn't responding.
24 [18:20:29] <@Thymo> Best fix would be to abort at TIG+50
24 [18:24:16] <@Thymo> After that you have about 2 seconds before the AGC expects the APS to be on.
24 [18:24:29] <@Thymo> That would explain the engine on command but no thrust.
10 [18:28:34] Connection to server lost
42 [18:28:43] You have set user mode +Zi
86 [18:28:43] [Entering away status]: You have been marked as being away
144 [18:28:44] ### Log session terminated ###
144 [18:28:44] ### Log session started ###
20 [18:28:44] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
23 [18:28:44] Channel topic is: Welcome to #nassp! Wiki: http://nassp.sf.net Forum: http://www.ibiblio.org/mscorbit/mscforum GitHub: https://github.com/dseagrav/NASSP
23 [18:28:44] Topic was set by Thymo!~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl on Wed Feb 22 16:30:28 2017
25 [18:28:44] <***> Buffer Playback...
25 [18:28:44] <@indy91> [18:22:04] P74 also doesn't start when you abort early, in P42
25 [18:28:44] <***> Playback Complete.
51 [18:29:20] niven.freenode.net [*@*] has set channel mode +cgnt
62 [18:29:20] Channel was created at Sun Jan 8 21:49:15 2017
15 [18:29:22] Channel synchronized in 38.861 seconds
24 [18:29:37] <@Thymo> Lost connection again >:(
25 [18:29:50] <@indy91> What was the last thing I said?
24 [18:29:51] <@Thymo> [18:10:13] <@indy91> Also, what happens if it never finds the bit? Last time I had some program alarms, I think.
24 [18:29:51] <@Thymo> [18:14:02] <@Thymo> Actually I might be wrong. ABMON is the abort monitor that checks for an abort initiated from the ground.
24 [18:29:51] <@Thymo> [18:15:48] <@Thymo> What alarm did you get?
24 [18:29:51] <@Thymo> [18:19:36] <@Thymo> Looks like nothing specifically happens if the abort fails. The AGC will probably crash after the APS isn't responding.
24 [18:29:51] <@Thymo> [18:20:29] <@Thymo> Best fix would be to abort at TIG+50
24 [18:29:51] <@Thymo> [18:24:16] <@Thymo> After that you have about 2 seconds before the AGC expects the APS to be on.
24 [18:29:51] <@Thymo> [18:24:29] <@Thymo> That would explain the engine on command but no thrust.
25 [18:31:15] <@indy91> But it does still nominally check for channel 30, bit 2, right?
25 [18:31:34] <@indy91> The LGC sends an abort signal to the Programer
24 [18:34:23] <@Thymo> Yes. The LGC sends the command. However it checks for an abort by either the LMP or MCC starting at TIG-7.5
25 [18:34:52] <@indy91> checks for abort by the LMP... what does that mean?
25 [18:35:13] <@indy91> The LGC gets the Stage Verify and of two abort bits
25 [18:35:17] <@indy91> either ascent or descent stage
25 [18:35:23] <@indy91> does it need something else in Sunburst?
24 [18:37:28] <@Thymo> It just waits for the abort discrete in channel 30 bit 2.
24 [18:37:57] <@Thymo> That's the only thing it checks if the stage was aborted.
25 [18:38:27] <@indy91> that one really should be set
25 [18:39:22] <@indy91> But I will check
24 [18:39:59] <@Thymo> Remember that it's inverted.
25 [18:48:24] <@indy91> hmm
25 [18:48:25] <@indy91> actually
25 [18:48:32] <@indy91> doesn't seem to change
25 [18:48:36] <@indy91> that is veeeeery weird
25 [19:10:13] <@indy91> before stage firing, channel 30 is 41460
25 [19:10:21] <@indy91> in octal
25 [19:10:35] <@indy91> after stage fire it's 61460
25 [19:14:24] <@indy91> that doesn't make any sense
25 [19:28:15] <@indy91> ok, it seems to be sent correctly after all
25 [19:28:36] <@indy91> maybe GetInputChannel just isn't correctly working
25 [19:29:08] <@indy91> after staging, the bit is definitely 1
2 [20:05:19] <@indy91> Thymo, what was that restartability flag we once tried?
25 [20:10:44] <@indy91> ok, more weirdness
25 [20:10:55] <@indy91> the bit gets saved in the wrong way
25 [20:12:54] <@indy91> actually, it might have been saved since the AGC was in a CSM
25 [20:18:20] <@indy91> got a P74!
25 [20:30:27] <@indy91> by having a 0 in that bit
25 [21:11:54] <@indy91> got through P74 and the APS burn
34 [21:21:43] indy91 [~indy91@2a02:8108:8b40:3aa8:e95b:c8ea:61be:23e4] has quit IRC: Quit: Leaving
20 [21:22:07] indy91 [~indy91@2a02:8108:8b40:3aa8:e95b:c8ea:61be:23e4] has joined #nassp
38 [21:22:07] ChanServ [ChanServ@services.] has set mode +o indy91
10 [00:39:00] Connection to server lost
42 [00:39:10] You have set user mode +Zi
86 [00:39:10] [Entering away status]: You have been marked as being away
144 [00:39:11] ### Log session terminated ###