spacepaste

Paste details

reply | raw

  1.  
  2. 144 [00:00:00] ### Log session started ###
  3. 20 [01:34:06] pg_ [~pg@ACaen-654-1-86-243.w81-48.abo.wanadoo.fr] has joined #nassp
  4. 34 [01:37:08] orbi4 [~orbi4@ACaen-654-1-29-20.w83-115.abo.wanadoo.fr] has quit IRC: Ping timeout: 260 seconds
  5. 34 [01:37:08] pg [~pg@ACaen-654-1-29-20.w83-115.abo.wanadoo.fr] has quit IRC: Ping timeout: 260 seconds
  6. 25 [02:07:08] <thewonderidiot> hmmm
  7. 25 [02:07:23] <thewonderidiot> 16 is not the fixed bank indicated there
  8. 25 [02:07:40] <thewonderidiot> it's effectively shifted up by one, so that's really fixed bank 7 that the alarm occurred in
  9. 25 [02:07:57] <thewonderidiot> 07,2000 is where the TC ALARM in FAKESTRT is
  10. 25 [02:07:59] <thewonderidiot> so that's not helpful
  11. 25 [02:08:09] <thewonderidiot> it would be much more useful to know where the CCSHOLE was hit
  12. 25 [02:08:15] <thewonderidiot> because that is a really weird thing to hit
  13. 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
  14. 25 [02:11:15] <thewonderidiot> oh you guys already got to that
  15. 25 [02:11:25] <thewonderidiot> lol
  16. 25 [02:15:01] <thewonderidiot> so yeah, FAKESTRT can only be entered when bit 12 of FLGWRD1 is 0
  17. 25 [02:17:34] <thewonderidiot> it looks like Sunburst *can* force a FAKESTRT if it really strongly wants to via ABORT2
  18. 25 [02:17:45] <thewonderidiot> by resetting that flag itself
  19. 25 [02:17:52] <thewonderidiot> but if it does that it WHIMPERs to get the restart
  20. 25 [02:17:58] <thewonderidiot> did the RESTART light come on or just PROG?
  21. 24 [03:11:00] <@Thymo> I think he had a full restart. FAKESTRT is called by GOPROG anyway.
  22. 24 [03:11:50] <@Thymo> Sunburst is doing a lot of stuff different. I don't understand it yet.
  23. 24 [03:16:55] <@Thymo> Why is BBANK shifted up?
  24. 144 [03:17:38] ### Log session terminated ###
  25. 144 [12:43:59] ### Log session started ###
  26. 20 [12:43:59] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
  27. 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
  28. 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
  29. 25 [12:43:59] <***> Buffer Playback...
  30. 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
  31. 25 [12:43:59] <thewonderidiot> [03:41:02] since FB is five bits wide, it occupies the most significant five bits
  32. 25 [12:43:59] <thewonderidiot> [03:41:58] so bank 7 would be 00111 in binary, but end up in the word like 00111xxxxxxxxxx
  33. 25 [12:43:59] <thewonderidiot> [03:42:16] encoding that as octal you end up with either 16xxx or 17xxx
  34. 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
  35. 25 [12:43:59] <thewonderidiot> [03:42:54] 016 >> 1 == 07
  36. 25 [12:43:59] <thewonderidiot> [03:43:29] and yeah, I spent a bit of time looking at it over dinner
  37. 25 [12:43:59] <thewonderidiot> [03:43:39] Niklas may have discovered a sort of design flaw in CCSHOLE
  38. 25 [12:43:59] <thewonderidiot> [03:44:24] just to narrate exactly what happened:
  39. 25 [12:43:59] <thewonderidiot> [03:44:28] he triggered a CCSHOLE
  40. 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
  41. 25 [12:43:59] <thewonderidiot> [03:45:22] ABORT2 loads the 1103 and TCs to BORTENT
  42. 25 [12:43:59] <thewonderidiot> [03:45:29] then program alarm things happen
  43. 25 [12:43:59] <thewonderidiot> [03:46:03] actually before program alarm things happen, Q is stored in RUPTREG4
  44. 25 [12:43:59] <thewonderidiot> [03:46:25] so RUPTREG4 is now pointing at the constant OCT40400 after the end of ABORT2
  45. 25 [12:44:00] <thewonderidiot> [03:46:37] so program alarm things happen, and it gets to MULTEXIT
  46. 25 [12:44:00] <thewonderidiot> [03:46:59] which loads RUPTREG4 and indexes it onto a TC 1
  47. 25 [12:44:00] <thewonderidiot> [03:47:15] so control is transferred to the position right after OCT40400
  48. 25 [12:44:00] <thewonderidiot> [03:47:37] which forcibly resets the restartability flag and WHIMPERs
  49. 25 [12:44:00] <thewonderidiot> [03:47:57] so then the computer restarts, it goes into GOPROG, and seemingly unavoidably runs FAKESTRT
  50. 25 [12:44:00] <thewonderidiot> [03:48:09] which immediately calls ALARM
  51. 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
  52. 25 [12:44:00] <thewonderidiot> [03:48:54] ....I'm not entirely sure it's possible to recover that CCSHOLE address
  53. 25 [12:44:00] <thewonderidiot> [03:49:13] unless we can somehow make the FAKESTRT not happen
  54. 25 [12:44:00] <thewonderidiot> [03:51:53] maybe if we send it through DOFSTART, it won't hit the call to FAKESTRT
  55. 25 [12:44:00] <thewonderidiot> [03:52:01] it will be incredibly destructive to erasable memory though
  56. 25 [12:44:00] <thewonderidiot> [03:52:16] but this is just a simulator so I think we can accept that :)
  57. 25 [12:44:00] <thewonderidiot> [03:52:50] okay, possible procedure to prevent FAKESTRT
  58. 25 [12:44:00] <thewonderidiot> [03:52:59] stick a 1 into ERESTORE, which is at 1353
  59. 25 [12:44:00] <thewonderidiot> [03:53:13] that tricks Sunburst into thinking a failure happened during the erasable memory test
  60. 25 [12:44:00] <thewonderidiot> [03:53:25] and so it doubts erasable and clears most of the important thing
  61. 25 [12:44:00] <thewonderidiot> [03:53:40] but I *think* avoids touching ALMCADR, and skips the call to FAKESTRT
  62. 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
  63. 25 [12:44:00] <thewonderidiot> [05:43:55] okay, I just tried it out, and the procedure is confirmed
  64. 25 [12:44:00] <thewonderidiot> [05:45:59] apparently just doing V30E with blank erasable memory triggers a CCSHOLE, which is really convenient
  65. 25 [12:44:00] <thewonderidiot> [05:46:35] normally when I do that, I get a restart and V15 N50 shows 01103, 00316, 41110
  66. 25 [12:44:00] <thewonderidiot> [05:47:06] so like expected, a CCSHOLE followed by a FAKESTRT
  67. 25 [12:44:00] <thewonderidiot> [05:47:25] if I then do V01N01E 1353E 1E
  68. 25 [12:44:00] <thewonderidiot> [05:47:44] sorry
  69. 25 [12:44:00] <thewonderidiot> [05:47:48] V21N01E 1353E 1E
  70. 25 [12:44:00] <thewonderidiot> [05:48:17] then I do V30E again to trigger the same CCSHOLE
  71. 25 [12:44:00] <thewonderidiot> [05:49:00] V15 N50 now shows 01103, 01103, 00000
  72. 25 [12:44:00] <thewonderidiot> [05:49:04] no 316 alarm
  73. 25 [12:44:00] <thewonderidiot> [05:49:51] and N31 shows 03134, 02000, 00000
  74. 25 [12:44:00] <thewonderidiot> [05:50:11] which would (hopefully) indicate a CCSHOLE in 01,3133
  75. 25 [12:44:00] <thewonderidiot> [05:50:32] and indeed, that is a TC CCSHOLE
  76. 25 [12:44:00] <thewonderidiot> [05:50:37] so that procedure should work
  77. 25 [12:44:00] <thewonderidiot> [05:50:42] it'll nuke erasable memory
  78. 25 [12:44:00] <thewonderidiot> [05:50:45] but eh :D
  79. 2 [12:44:00] <thewonderidiot> [06:03:43] Thymo: please pass my monologue on to Niklas tomorrow morning!
  80. 25 [12:44:00] <***> Playback Complete.
  81. 51 [12:44:29] niven.freenode.net [*@*] has set channel mode +cgnt
  82. 62 [12:44:29] Channel was created at Sun Jan 8 21:49:15 2017
  83. 15 [12:44:37] Channel synchronized in 37.948 seconds
  84. 24 [12:44:42] <@Thymo> Hey
  85. 25 [12:45:58] <@indy91> hey
  86. 25 [12:46:58] <@indy91> Did you try my Sunburst scenario yet? Did you also get the PIPA fail alarm like eddievhfan1984?
  87. 24 [12:48:52] <@Thymo> I didn't. Mike came up with a procedure. Are you ready to receive a monologue?
  88. 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
  89. 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
  90. 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
  91. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:42:16] encoding that as octal you end up with either 16xxx or 17xxx
  92. 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
  93. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:42:54] 016 >> 1 == 07
  94. 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
  95. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:43:39] Niklas may have discovered a sort of design flaw in CCSHOLE
  96. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:44:24] just to narrate exactly what happened:
  97. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:44:28] he triggered a CCSHOLE
  98. 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
  99. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:45:22] ABORT2 loads the 1103 and TCs to BORTENT
  100. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:45:29] then program alarm things happen
  101. 24 [12:49:22] <@Thymo> [12:43:59] <thewonderidiot> [03:46:03] actually before program alarm things happen, Q is stored in RUPTREG4
  102. 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
  103. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:46:37] so program alarm things happen, and it gets to MULTEXIT
  104. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:46:59] which loads RUPTREG4 and indexes it onto a TC 1
  105. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:47:15] so control is transferred to the position right after OCT40400
  106. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:47:37] which forcibly resets the restartability flag and WHIMPERs
  107. 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
  108. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:48:09] which immediately calls ALARM
  109. 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
  110. 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
  111. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:49:13] unless we can somehow make the FAKESTRT not happen
  112. 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
  113. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:52:01] it will be incredibly destructive to erasable memory though
  114. 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 :)
  115. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:52:50] okay, possible procedure to prevent FAKESTRT
  116. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:52:59] stick a 1 into ERESTORE, which is at 1353
  117. 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
  118. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:53:25] and so it doubts erasable and clears most of the important thing
  119. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [03:53:40] but I *think* avoids touching ALMCADR, and skips the call to FAKESTRT
  120. 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
  121. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:43:55] okay, I just tried it out, and the procedure is confirmed
  122. 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
  123. 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
  124. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:06] so like expected, a CCSHOLE followed by a FAKESTRT
  125. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:25] if I then do V01N01E 1353E 1E
  126. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:44] sorry
  127. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:47:48] V21N01E 1353E 1E
  128. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:48:17] then I do V30E again to trigger the same CCSHOLE
  129. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:49:00] V15 N50 now shows 01103, 01103, 00000
  130. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:49:04] no 316 alarm
  131. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:49:51] and N31 shows 03134, 02000, 00000
  132. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:11] which would (hopefully) indicate a CCSHOLE in 01,3133
  133. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:32] and indeed, that is a TC CCSHOLE
  134. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:37] so that procedure should work
  135. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:42] it'll nuke erasable memory
  136. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [05:50:45] but eh :D
  137. 24 [12:49:22] <@Thymo> [12:44:00] <thewonderidiot> [06:03:43] Thymo: please pass my monologue on to Niklas tomorrow morning!
  138. 25 [12:50:16] <@indy91> woooow
  139. 24 [12:50:16] <@Thymo> So we can find out where you got that CCSHOLE but you will nuke erasable memory in the process.
  140. 25 [12:50:31] <@indy91> no problem, I can also reload the scenario :D
  141. 25 [12:50:34] <@indy91> always*
  142. 24 [12:51:36] <@Thymo> So make sure you do V21N01E 1353E 1E before the restart and then we'll have the debug info.
  143. 25 [12:53:20] <@indy91> Do I have to do the procedure as close as possible to the restart?
  144. 25 [12:53:59] <@indy91> Or does ERESTORE only do something during a restart?
  145. 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.
  146. 24 [12:54:54] <@Thymo> We basically force the AGC to do a full restart because memory failed which bypasses FAKESTRT.
  147. 24 [12:55:07] <@Thymo> So we keep the CADR of the CCSHOLE
  148. 24 [12:56:04] <@Thymo> thewonderidiot: Remind me about yaDSKY when you get on. I keep forgetting to mention it.
  149. 25 [13:00:11] <@indy91> just did the procedure
  150. 25 [13:00:11] <@indy91> hope it gives nice alarm data now
  151. 25 [13:00:11] <@indy91> 01103, 00000, 00000
  152. 25 [13:00:11] <@indy91> 02422, 34006, 00000
  153. 25 [13:00:11] <@indy91> awesome
  154. 25 [13:00:11] <@indy91> now let's find where that is :D
  155. 25 [13:06:23] <@indy91> still don't know how to convert that into bank...
  156. 24 [13:06:38] <@Thymo> I think it's in CKTRMCTR in P-AXIS_REACTION_CONTROL_SYSTEM_AUTOPILOT.agc
  157. 24 [13:07:01] <@Thymo> Bank 16, return adres 2422
  158. 25 [13:07:06] <@indy91> looking at that right now, too
  159. 25 [13:07:28] <@indy91> so something with the gimbal drive
  160. 24 [13:07:44] <@Thymo> COUNTDOWN FOR FORCED GTS ENTRY.
  161. 24 [13:08:22] <@Thymo> Erasable bank also checks out.
  162. 24 [13:09:13] <@Thymo> What's GTS?
  163. 25 [13:12:48] <@indy91> Gimbal Trim System or something like that
  164. 25 [13:13:50] <@indy91> yep
  165. 24 [13:14:56] <@Thymo> It happens right at ignition doesn't it?
  166. 25 [13:15:08] <@indy91> yep
  167. 25 [13:15:17] <@indy91> for a split second there is an engine on signal
  168. 24 [13:15:28] <@Thymo> Is FORCETRM a padload?
  169. 25 [13:15:29] <@indy91> So I guess it happens when it wants to start using the GTS
  170. 24 [13:15:48] <@Thymo> Address 1746 ebank 6
  171. 25 [13:16:39] <@indy91> FORCETRM
  172. 25 [13:17:32] <@indy91> nothing is loaded there
  173. 25 [13:17:32] <@indy91> in the padload
  174. 25 [13:17:53] <@indy91> But most addresses around it are used in the padload
  175. 24 [13:17:54] <@Thymo> I think that oone became invalid somehow
  176. 25 [13:18:16] <@indy91> And it says: "PARAMETERS IN ERASABLE LOAD:"
  177. 25 [13:18:36] <@indy91> So I guess the problem is that a padloaded value is missing in FORCETRM?
  178. 25 [13:19:08] <@indy91> CCSHOLE happens because it's +0
  179. 25 [13:19:15] <@indy91> Which is of course the case if nothing was loaded
  180. 25 [13:19:18] <@indy91> that's gotta be it
  181. 24 [13:19:42] <@Thymo> Yes. If it's not padloaded it will be +0. The CCSHOLE only triggers on +0
  182. 25 [13:19:47] <@indy91> yep
  183. 25 [13:19:54] <@indy91> ok
  184. 25 [13:19:57] <@indy91> what does it want there :D
  185. 25 [13:21:54] <@indy91> maybe I find something in the Sundance GSOP
  186. 25 [13:22:04] <@indy91> But it's likely Sunburst specific
  187. 24 [13:22:59] <@Thymo> I think -0 will do. That starts smartjob.
  188. 25 [13:23:50] <@indy91> is it EMEM3346?
  189. 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.
  190. 25 [13:24:58] <@indy91> So I will try EMEM3346 77777
  191. 24 [13:25:21] <@Thymo> Maybe. Do you have a padload for DRIVELIM?
  192. 24 [13:25:34] <@Thymo> One below that.
  193. 25 [13:25:56] <@indy91> nope
  194. 25 [13:26:06] <@indy91> I only have COUNTBOX, a few above
  195. 24 [13:26:29] <@Thymo> COUNTBOX +3
  196. 25 [13:26:31] <@indy91> I think I might be a missing a few numbers there
  197. 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).
  198. 25 [13:28:50] <@indy91> then I'll only try the -0 in 3346 first
  199. 25 [13:29:49] <@indy91> surely that would give new program alarms
  200. 25 [13:30:46] <@indy91> no alarm!
  201. 25 [13:30:56] <@indy91> at 10% throttle
  202. 25 [13:31:25] <@indy91> 100%
  203. 25 [13:31:26] <@indy91> cutoff
  204. 25 [13:31:37] <@indy91> perfect orbit
  205. 25 [13:31:42] <@indy91> exactly at perigee
  206. 25 [13:31:48] <@indy91> so flight path angle 0°
  207. 25 [13:31:56] <@indy91> which is exactly what the SCOT said it should be
  208. 25 [13:32:25] <@indy91> orbit is 112x186
  209. 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
  210. 25 [13:33:49] <@indy91> But I think everything is working exactly as it should
  211. 25 [13:35:09] <@indy91> Apollo 5 can continue!
  212. 25 [13:35:16] <@indy91> The next DPS burn is the really exciting one
  213. 25 [13:35:28] <@indy91> powered descent simulation, with braking and approach phase
  214. 24 [13:35:32] <@Thymo> Woo!
  215. 25 [13:35:56] <@indy91> simply loading -0 instead of +0 fixed it :D
  216. 25 [13:36:11] <@indy91> what a great computer you are, AGC
  217. 25 [13:37:24] <@indy91> Interestingly, after cutoff the LGC hasn't commanded throttle down yet
  218. 25 [13:37:37] <@indy91> Usually the LGC will command maximum negative throttle commands
  219. 25 [13:37:42] <@indy91> after cutoff
  220. 25 [13:38:08] <@indy91> But Sunburst also doesn't always send an "Engine Off" signal, so, just more weirdness
  221. 25 [13:39:12] <@indy91> oh, and planned orbit is 116x179 after the DPS burn
  222. 25 [13:39:14] <@indy91> not bad
  223. 25 [13:39:37] <@indy91> And I think it might have been even better without the DPS bug
  224. 25 [13:39:43] <@indy91> fixed that one now
  225. 25 [13:43:30] <@indy91> the only reason the perigee is off is because the burn happens at 112NM altitude
  226. 25 [13:43:42] <@indy91> TIG is fixed
  227. 25 [13:43:58] <@indy91> and I guess the insertion orbit was slightly off
  228. 25 [13:44:05] <@indy91> no big deal
  229. 25 [13:45:07] <@indy91> oh, and it's missing tailoff thrust
  230. 25 [13:45:12] <@indy91> I should change those padloads
  231. 25 [13:45:23] <@indy91> 112x176 now
  232. 25 [13:45:34] <@indy91> would have been perfect with thrust tailoff
  233. 25 [13:46:06] <@indy91> now waiting for P00, saving and then checking all the padloaded values for the long DPS burn
  234. 25 [13:50:03] <@indy91> Sunburst just went further into the flight than Apollo 5 ever did!
  235. 24 [13:51:14] <@Thymo> Awesome!
  236. 24 [13:51:46] <@Thymo> When you finish this it will be a nice item for the Virtual AGC mailing list.
  237. 25 [13:51:51] <@indy91> oh yes
  238. 25 [13:52:06] <@indy91> The second DPS burn is 12 minutes long. Then it will randomly throttle around
  239. 25 [13:52:15] <@indy91> and then fire in the hole - abort test
  240. 25 [13:52:29] <@indy91> and then an APS burn, of course
  241. 25 [13:52:44] <@indy91> a very short one, just after the abort
  242. 25 [13:52:53] <@indy91> abort staging*
  243. 25 [13:53:46] <@indy91> so that is the PDI simulation
  244. 25 [13:53:59] <@indy91> mostly out-of-plane, I think
  245. 25 [13:56:06] <@indy91> save at T+4:33:00
  246. 25 [13:56:10] <@indy91> 30*
  247. 25 [13:56:19] <@indy91> and in 3 minutes the fun should begin
  248. 25 [13:56:27] <@indy91> I expect new program alarms, of course :D
  249. 25 [13:56:54] <@indy91> oh noo
  250. 25 [13:56:57] <@indy91> sunset
  251. 25 [13:57:03] <@indy91> burn will happen in the dark
  252. 25 [13:57:13] <@indy91> Program 32!
  253. 25 [13:57:19] <@indy91> restart
  254. 25 [13:57:39] <@indy91> I think it might be stuck
  255. 25 [13:57:51] <@indy91> COMP ACTY light stays on
  256. 25 [13:57:59] <@indy91> it displayed the V15 N50, but it's all 0
  257. 25 [13:58:38] <@indy91> ok, new alarms
  258. 25 [13:58:49] <@indy91> 1202, 316 and 41110
  259. 25 [13:59:04] <@indy91> V15 N31
  260. 25 [13:59:14] <@indy91> 02340, 02003
  261. 24 [14:01:31] <@Thymo> Fun.
  262. 24 [14:02:14] <@Thymo> The last alarm is 1110 Restart but no groups active
  263. 24 [14:03:17] <@Thymo> V01N10E 77E
  264. 24 [14:03:33] <@Thymo> Check the restart monitor
  265. 24 [14:04:01] <@Thymo> The groundstation program would be really handy for this.
  266. 25 [14:08:00] <@indy91> The only realistic method if interacting with LM-1 :D
  267. 25 [14:08:11] <@indy91> of*
  268. 25 [14:13:18] <@indy91> so, according to the SCOT some sort of ignition algorithm is running when P32 starts
  269. 25 [14:13:31] <@indy91> so that's probably where it already fails
  270. 25 [14:17:14] <@indy91> https://www.ibiblio.org/apollo/listings/Sunburst120/MISSION_PHASE_11-DPS2_FITH_APS1.agc.html
  271. 25 [14:17:14] <Guenter> [ Assembly listing generated by yaYUL ] - www.ibiblio.org
  272. 25 [14:17:29] <@indy91> does that artificially cause a restart right at the beginning?
  273. 25 [14:19:04] <@indy91> ok, I think I caused the 1202 alarm
  274. 25 [14:19:12] <@indy91> by typing stuff into the DSKY
  275. 25 [14:19:18] <@indy91> now I get a 410 alarm instead
  276. 24 [14:19:27] <@Thymo> The SETRSTRT flag? That enables restartability.
  277. 25 [14:19:32] <@indy91> oh, ok
  278. 25 [14:19:46] <@indy91> first a restart with no program alarm code in V15 N50 and then 410
  279. 25 [14:20:20] <@indy91> but it didn't go to P00 yet
  280. 24 [14:20:35] <@Thymo> 00410 OVERFLOW PRIOR TO OR DURING COMPUTATION OF ACS OR AFCS (MP 11)
  281. 25 [14:20:57] <@indy91> yeah, I am in MP11
  282. 25 [14:21:21] <@indy91> I'll let it running until in goes to P00
  283. 25 [14:21:29] <@indy91> should switch to P42
  284. 25 [14:21:33] <@indy91> but that will probably fail
  285. 24 [14:21:34] <@Thymo> How did you trigger a 1202?
  286. 25 [14:22:45] <@indy91> by typing V15 N31, I think
  287. 25 [14:23:12] <@indy91> yeah, it's stuck. There should have been ignition by now.
  288. 24 [14:23:15] <@Thymo> Possible if the AGC was under heavy load.
  289. 25 [14:23:19] <@indy91> yep
  290. 25 [14:23:30] <@indy91> it's still on full comp activity
  291. 25 [14:23:50] <@indy91> yeah, stuck
  292. 25 [14:23:59] <@indy91> as soon as I type anything nothing happens at first
  293. 25 [14:24:02] <@indy91> and then it goes to P00
  294. 24 [14:24:18] <@Thymo> Comp activity is a light that the computer arbitrarily turns on and off. It might simply be glitched out.
  295. 25 [14:24:27] <@indy91> could be
  296. 25 [14:24:36] <@indy91> it was on for 99% of the time
  297. 25 [14:24:39] <@indy91> but not 100%
  298. 25 [14:24:54] <@indy91> Where in the code is the 410 alarm?
  299. 24 [14:25:08] <@Thymo> Then it's probably stuck in some computation.
  300. 25 [14:25:19] <@indy91> yeah
  301. 25 [14:25:30] <@indy91> I would be some more missing padload stuff
  302. 25 [14:25:40] <@indy91> guess*
  303. 25 [14:26:32] <@indy91> ACS or AFCS are the desired acceleration vector, I think
  304. 25 [14:28:07] <@indy91> Could of course also be a wrong padload
  305. 25 [14:28:15] <@indy91> the MP11 targets I used are from the SCOT
  306. 25 [14:28:24] <@indy91> which is not for the correct launch day
  307. 25 [14:29:03] <@indy91> and it's totally different in the AS-206 document as compared with the SCOT
  308. 25 [14:29:15] <@indy91> So, this might be launch time dependant
  309. 25 [14:29:48] <@indy91> or wait a minute...
  310. 25 [14:29:58] <@indy91> I think the SCOT values are in the wrong coordinate system
  311. 25 [14:30:05] <@indy91> So I'll try the one from AS-206
  312. 25 [14:30:10] <@indy91> one*
  313. 25 [14:32:36] <@indy91> yeah, SCOT has Earth Centered Inertial (ECI) coordinates for the MP11 target vector
  314. 24 [14:32:37] <@Thymo> The AGC went into MULTFAIL. You had more alarms than those 3.
  315. 25 [14:32:57] <@indy91> but the padload should be IMU coordinates
  316. 25 [14:33:16] <@indy91> I think I caused almost all alarms, except for 410
  317. 25 [14:33:21] <@indy91> and the first restart
  318. 25 [14:33:48] <@indy91> 410 is the only alarm that was there before I started using the DSKY
  319. 24 [14:33:49] <@Thymo> Yeah. Can you check the restart monitor?
  320. 25 [14:34:25] <@indy91> I'll try the AS-206 padload target vector first
  321. 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
  322. 25 [14:35:09] <@indy91> no restart!
  323. 25 [14:35:22] <@indy91> and no alarms... yet
  324. 25 [14:35:33] <@indy91> COMP ACTY light not stuck anymore!
  325. 25 [14:35:44] <@indy91> it stayed on for a while, but I think it finished calculating
  326. 25 [14:35:55] <@indy91> this might work!
  327. 25 [14:38:03] <@indy91> P42!
  328. 25 [14:38:25] <@indy91> I wonder if the throttle at 100% was also something broken by my control logic update...
  329. 25 [14:38:34] <@indy91> ignition
  330. 25 [14:39:30] <@indy91> looks good
  331. 25 [14:39:40] <@indy91> but I doubt it will properly do the throttle test
  332. 25 [14:39:46] <@indy91> we'll see
  333. 25 [14:39:57] <@indy91> first 10 more minutes of the burn
  334. 24 [14:40:40] <@Thymo> That's a long burn.
  335. 25 [14:40:48] <@indy91> yeah
  336. 25 [14:41:26] <@indy91> I guess the test is a late PDI abort
  337. 25 [14:41:27] <@indy91> very late
  338. 25 [14:42:09] <@indy91> rip
  339. 25 [14:42:12] <@indy91> gimbal lock :D
  340. 24 [14:42:34] <@Thymo> Haha
  341. 25 [14:42:35] <@indy91> I think it might have had some sort of control loss
  342. 25 [14:42:45] <@indy91> about 4 minutes into the burn
  343. 25 [14:43:30] <@indy91> I'll have to try that again, to see if it first had gimbal lock, or first control loss
  344. 25 [14:43:35] <@indy91> I think it was control loss first
  345. 25 [14:43:44] <@indy91> in any case, the target vector might still be bad
  346. 25 [14:43:53] <@indy91> causing it to be closer to gimbal lock than necessary
  347. 25 [14:56:09] <@indy91> next try
  348. 25 [14:56:20] <@indy91> I have edited the scenario so that it starts at 10% throttle
  349. 25 [15:00:46] <@indy91> hmm
  350. 25 [15:00:53] <@indy91> at some point it stops issuing RCS commands
  351. 25 [15:00:58] <@indy91> and then it starts spinning
  352. 25 [15:02:31] <@indy91> it did go to the random throttle command sequence though
  353. 25 [15:04:16] <@indy91> hmm
  354. 25 [15:04:24] <@indy91> there is an interesting padload related to that
  355. 25 [15:04:35] <@indy91> DAPOFFDT, Time from TIG+26 in MP11 to DAP Turn-Off
  356. 25 [15:04:42] <@indy91> 162 seconds
  357. 25 [15:07:15] <@indy91> "DAP is scheduled to be turned off for 4 sec in MP11 burn by changing fresh start initialization"
  358. 24 [15:07:27] <@Thymo> Why would anyone want to do that?
  359. 25 [15:07:34] <@indy91> no idea
  360. 25 [15:07:45] <@indy91> source code says "set to 0 or negative to inhibit DAP turn-off"
  361. 25 [15:07:48] <@indy91> I'll try that
  362. 25 [15:08:25] <@indy91> and it didn't turn it off for 4 seconds
  363. 25 [15:08:32] <@indy91> seemed like it never issued any commands anymore
  364. 25 [15:09:18] <@indy91> after the random throttle sequence it goes to 100% again
  365. 25 [15:09:24] <@indy91> and then I have to do the abort staging
  366. 24 [15:09:40] <@Thymo> It starts a special cdu downlink
  367. 25 [15:09:55] <@indy91> some test then
  368. 24 [15:10:14] <@Thymo> Which is supposed to turn it on again after it's done.
  369. 25 [15:10:21] <@indy91> hmm
  370. 25 [15:10:24] <@indy91> weird
  371. 25 [15:10:34] <@indy91> might be a broken feature, who knows
  372. 25 [15:10:58] <@indy91> I'll have to find a better document with planned Apollo 5 tests
  373. 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.
  374. 24 [15:17:07] <@Thymo> That that DAP inhibit work?
  375. 25 [15:17:15] <@indy91> still testing
  376. 25 [15:17:23] <@indy91> haven't reached that time yet
  377. 25 [15:17:37] <@indy91> but 162 + 26 seconds after ignition seem like the time when it happened
  378. 25 [15:20:06] <@indy91> seems like the DAP stayed working
  379. 25 [15:20:08] <@indy91> lots of RCS firing
  380. 25 [15:23:03] <@indy91> hmm
  381. 25 [15:23:11] <@indy91> it shouldn't stay at 100%
  382. 25 [15:23:20] <@indy91> it should do some throttle recovery for a few minutes
  383. 25 [15:23:26] <@indy91> oh
  384. 25 [15:23:27] <@indy91> P43!
  385. 25 [15:23:31] <@indy91> whatever that one does, lol
  386. 25 [15:23:52] <@indy91> approach phase
  387. 25 [15:23:56] <@indy91> but throttle is at 100%
  388. 25 [15:24:07] <@indy91> it was just at a lower setting for a few seconds
  389. 25 [15:24:39] <@indy91> oh fun
  390. 25 [15:24:41] <@indy91> another 410 alarm
  391. 25 [15:25:12] <@indy91> oops, did the abort stage too early
  392. 25 [15:25:23] <@indy91> It went into P44, where I thought I had to do staging
  393. 25 [15:25:31] <@indy91> P44 is "DPS2 Burn - Random Throttle" :D
  394. 10 [16:20:52] Connection to server lost
  395. 42 [16:21:03] You have set user mode +Zi
  396. 86 [16:21:03] [Entering away status]: You have been marked as being away
  397. 144 [16:21:04] ### Log session terminated ###
  398. 144 [16:21:04] ### Log session started ###
  399. 20 [16:21:04] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
  400. 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
  401. 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
  402. 57 [16:21:57] indy91 is indy91!~indy91@2a02:8108:8b40:3aa8:e95b:c8ea:61be:23e4
  403. 57 [16:21:57] indy91's real name: realname
  404. 58 [16:21:57] indy91's channels: @#nassp
  405. 60 [16:21:57] indy91's server: leguin.freenode.net - Umeå, SE, EU
  406. 61 [16:21:57] indy91's info: is using a secure connection
  407. 59 [16:21:57] indy91's idle time: 0d 0h 55m 55s
  408. 59 [16:21:57] indy91's signon time: Fri Jun 2 11:38:06 2017
  409. 61 [16:21:57] indy91 is authenticated as indy91
  410. 61 [16:21:57] indy91 WHOIS info from leguin.freenode.net
  411. 51 [16:21:57] niven.freenode.net [*@*] has set channel mode +cgnt
  412. 62 [16:21:57] Channel was created at Sun Jan 8 21:49:15 2017
  413. 15 [16:21:57] Channel synchronized in 53.43 seconds
  414. 10 [16:53:38] Connection to server lost
  415. 42 [16:53:48] You have set user mode +Zi
  416. 86 [16:53:48] [Entering away status]: You have been marked as being away
  417. 144 [16:53:48] ### Log session terminated ###
  418. 144 [16:53:48] ### Log session started ###
  419. 20 [16:53:48] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
  420. 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
  421. 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
  422. 51 [16:54:25] niven.freenode.net [*@*] has set channel mode +cgnt
  423. 62 [16:54:25] Channel was created at Sun Jan 8 21:49:15 2017
  424. 15 [16:54:28] Channel synchronized in 39.954 seconds
  425. 25 [16:55:25] <@indy91> The LM I am using is more than 1000 kg too heavy
  426. 25 [16:55:44] <@indy91> must be the legs
  427. 24 [17:04:18] <@Thymo> Lost connection. Did you say anything before "The LM I am using is more than 1000 kg too heavy"?
  428. 25 [17:05:50] <@indy91> not for the last 90 minutes
  429. 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
  430. 25 [17:06:57] <@indy91> that's why it doesn't really throttle down
  431. 25 [17:07:36] <@indy91> throttle down!
  432. 25 [17:07:43] <@indy91> just like during a lunar landing
  433. 25 [17:08:35] <@indy91> 1405, 315 alarm
  434. 25 [17:08:51] <@indy91> it controls terribly at low mass
  435. 25 [17:09:17] <@indy91> I think I missed the staging time
  436. 25 [17:10:03] <@indy91> But all in all this was a much better attempt
  437. 25 [17:10:35] <@indy91> maybe there is a mass difference between what the LGC thinks and actual mass
  438. 25 [17:12:37] <@indy91> LGC mass is 6245 kg, actual mass 6000 kg
  439. 25 [17:13:31] <@indy91> Might also be a difference in DPS mass flow rate
  440. 25 [17:13:44] <@indy91> I'll give it 200kg more and will try to remember to do staging
  441. 24 [17:14:14] <@Thymo> 1405 DV ALARM. ENGINE ON BUT NO THRUST. 315 FORGETIT
  442. 25 [17:14:37] <@indy91> might be because it's expecting APS thrust
  443. 25 [17:14:40] <@indy91> yeah
  444. 25 [17:15:36] <@indy91> I didn't know that until a few days ago, but the LGC actually sends commands to the Programer
  445. 25 [17:15:47] <@indy91> stuff like staging, RCS Pressurization etc.
  446. 25 [17:16:21] <@indy91> I always thought it was the other way around. Programer sends commands to LGC and all other systems
  447. 25 [17:16:41] <@indy91> But Sunburst is really more in control of the LM than any other LGC version
  448. 24 [17:18:43] <@Thymo> How does it send the commands? Through input channels?
  449. 24 [17:18:49] <@Thymo> s/input/output
  450. 2 [17:18:49] <Guenter> Thymo meant to say: How does it send the commands? Through output channels?
  451. 25 [17:19:40] <@indy91> I am not sure yet
  452. 25 [17:19:45] <@indy91> there is a LMP routine
  453. 25 [17:19:48] <@indy91> LM Programer
  454. 25 [17:19:57] <@indy91> with some sort of code
  455. 25 [17:20:10] <@indy91> https://www.ibiblio.org/apollo/listings/Sunburst120/LMP_COMMAND_ROUTINES.agc.html
  456. 25 [17:20:10] <Guenter> [ Assembly listing generated by yaYUL ] - www.ibiblio.org
  457. 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
  458. 25 [17:20:35] <@indy91> THE DOWNLINK.
  459. 25 [17:23:42] <@indy91> Systems Handbook has a list of commands
  460. 25 [17:23:56] <@indy91> seems pretty possible to create the LM Programer
  461. 25 [17:25:43] <@indy91> THRUST AT MAX FOR 1 MORE SEC AND ABORT
  462. 25 [17:25:49] <@indy91> that's what I have to look for
  463. 25 [17:26:01] <@indy91> random throttle sequence, full throttle, press abort stage
  464. 25 [17:27:32] <@indy91> during the burn the LM is directly over Houston
  465. 25 [17:29:36] <@indy91> throttle down and P43
  466. 25 [17:29:42] <@indy91> don't miss it this time :D
  467. 25 [17:34:23] <@indy91> didn't miss it, but it never started P74 for the APS burn
  468. 25 [17:34:46] <@indy91> it should monitor the abort stage bit and/or the stage bit
  469. 25 [17:37:04] <@indy91> It looks for the Stage Verify bit, channel 30 bit 2
  470. 25 [17:37:25] <@indy91> that should be set at staging
  471. 25 [17:38:49] <@indy91> but everything until then worked exactly as per SCOT
  472. 25 [17:42:41] <@indy91> in any case, I am pretty sure the MP11 target vector is working
  473. 2 [18:01:42] <@indy91> Thymo, can you check for me a few things in the code?
  474. 25 [18:01:46] <@indy91> 1. when does it start/stop monitoring the staging bit.
  475. 25 [18:01:55] <@indy91> 2. Is it looking for the inverted state, like usual for input bits.
  476. 25 [18:02:17] <@indy91> I had a 3rd question, but I forgot :D
  477. 24 [18:04:11] <@Thymo> Still during MP11?
  478. 25 [18:04:35] <@indy91> yeah
  479. 25 [18:04:36] <@indy91> all in here
  480. 25 [18:04:37] <@indy91> https://www.ibiblio.org/apollo/listings/Sunburst120/MISSION_PHASE_11-DPS2_FITH_APS1.agc.html#41424D4F4E
  481. 25 [18:04:38] <Guenter> [ Assembly listing generated by yaYUL ] - www.ibiblio.org
  482. 25 [18:05:08] <@indy91> Maybe the timing of the staging is more critical. After all the LGC commands it itself
  483. 24 [18:05:30] <@Thymo> It does a bitwise AND on channel 30 bit 2.
  484. 24 [18:06:37] <@Thymo> And it jumps to FITHGCMD if it's zero.
  485. 24 [18:06:42] <@Thymo> So it is inverted.
  486. 25 [18:07:15] <@indy91> right
  487. 25 [18:07:21] <@indy91> When does it start looking for it?
  488. 25 [18:07:24] <@indy91> in P44 or earlier?
  489. 24 [18:07:40] <@Thymo> TIG-7.5
  490. 24 [18:07:54] <@Thymo> At the same time as the ullage.
  491. 25 [18:08:14] <@indy91> wow, so very early
  492. 24 [18:08:16] <@Thymo> After that every .5 seconds until it detects staging.
  493. 25 [18:08:59] <@indy91> the bit is set in the lemmesh.cpp functions
  494. 25 [18:09:22] <@indy91> So it would be weird if it isn't set
  495. 25 [18:10:13] <@indy91> Also, what happens if it never finds the bit? Last time I had some program alarms, I think.
  496. 24 [18:14:02] <@Thymo> Actually I might be wrong. ABMON is the abort monitor that checks for an abort initiated from the ground.
  497. 24 [18:15:48] <@Thymo> What alarm did you get?
  498. 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.
  499. 24 [18:20:29] <@Thymo> Best fix would be to abort at TIG+50
  500. 24 [18:24:16] <@Thymo> After that you have about 2 seconds before the AGC expects the APS to be on.
  501. 24 [18:24:29] <@Thymo> That would explain the engine on command but no thrust.
  502. 10 [18:28:34] Connection to server lost
  503. 42 [18:28:43] You have set user mode +Zi
  504. 86 [18:28:43] [Entering away status]: You have been marked as being away
  505. 144 [18:28:44] ### Log session terminated ###
  506. 144 [18:28:44] ### Log session started ###
  507. 20 [18:28:44] Thymo [~Thymo@524ACC90.cm-4-3d.dynamic.ziggo.nl] has joined #nassp
  508. 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
  509. 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
  510. 25 [18:28:44] <***> Buffer Playback...
  511. 25 [18:28:44] <@indy91> [18:22:04] P74 also doesn't start when you abort early, in P42
  512. 25 [18:28:44] <***> Playback Complete.
  513. 51 [18:29:20] niven.freenode.net [*@*] has set channel mode +cgnt
  514. 62 [18:29:20] Channel was created at Sun Jan 8 21:49:15 2017
  515. 15 [18:29:22] Channel synchronized in 38.861 seconds
  516. 24 [18:29:37] <@Thymo> Lost connection again >:(
  517. 25 [18:29:50] <@indy91> What was the last thing I said?
  518. 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.
  519. 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.
  520. 24 [18:29:51] <@Thymo> [18:15:48] <@Thymo> What alarm did you get?
  521. 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.
  522. 24 [18:29:51] <@Thymo> [18:20:29] <@Thymo> Best fix would be to abort at TIG+50
  523. 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.
  524. 24 [18:29:51] <@Thymo> [18:24:29] <@Thymo> That would explain the engine on command but no thrust.
  525. 25 [18:31:15] <@indy91> But it does still nominally check for channel 30, bit 2, right?
  526. 25 [18:31:34] <@indy91> The LGC sends an abort signal to the Programer
  527. 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
  528. 25 [18:34:52] <@indy91> checks for abort by the LMP... what does that mean?
  529. 25 [18:35:13] <@indy91> The LGC gets the Stage Verify and of two abort bits
  530. 25 [18:35:17] <@indy91> either ascent or descent stage
  531. 25 [18:35:23] <@indy91> does it need something else in Sunburst?
  532. 24 [18:37:28] <@Thymo> It just waits for the abort discrete in channel 30 bit 2.
  533. 24 [18:37:57] <@Thymo> That's the only thing it checks if the stage was aborted.
  534. 25 [18:38:27] <@indy91> that one really should be set
  535. 25 [18:39:22] <@indy91> But I will check
  536. 24 [18:39:59] <@Thymo> Remember that it's inverted.
  537. 25 [18:48:24] <@indy91> hmm
  538. 25 [18:48:25] <@indy91> actually
  539. 25 [18:48:32] <@indy91> doesn't seem to change
  540. 25 [18:48:36] <@indy91> that is veeeeery weird
  541. 25 [19:10:13] <@indy91> before stage firing, channel 30 is 41460
  542. 25 [19:10:21] <@indy91> in octal
  543. 25 [19:10:35] <@indy91> after stage fire it's 61460
  544. 25 [19:14:24] <@indy91> that doesn't make any sense
  545. 25 [19:28:15] <@indy91> ok, it seems to be sent correctly after all
  546. 25 [19:28:36] <@indy91> maybe GetInputChannel just isn't correctly working
  547. 25 [19:29:08] <@indy91> after staging, the bit is definitely 1
  548. 2 [20:05:19] <@indy91> Thymo, what was that restartability flag we once tried?
  549. 25 [20:10:44] <@indy91> ok, more weirdness
  550. 25 [20:10:55] <@indy91> the bit gets saved in the wrong way
  551. 25 [20:12:54] <@indy91> actually, it might have been saved since the AGC was in a CSM
  552. 25 [20:18:20] <@indy91> got a P74!
  553. 25 [20:30:27] <@indy91> by having a 0 in that bit
  554. 25 [21:11:54] <@indy91> got through P74 and the APS burn
  555. 34 [21:21:43] indy91 [~indy91@2a02:8108:8b40:3aa8:e95b:c8ea:61be:23e4] has quit IRC: Quit: Leaving
  556. 20 [21:22:07] indy91 [~indy91@2a02:8108:8b40:3aa8:e95b:c8ea:61be:23e4] has joined #nassp
  557. 38 [21:22:07] ChanServ [ChanServ@services.] has set mode +o indy91
  558. 10 [00:39:00] Connection to server lost
  559. 42 [00:39:10] You have set user mode +Zi
  560. 86 [00:39:10] [Entering away status]: You have been marked as being away
  561. 144 [00:39:11] ### Log session terminated ###
  562.  
Powered by spacepaste. Paste removal.