[13:44:07] NASSP Logging has been started by thymo [13:44:09] There he is [13:48:50] hey Thymo, Guenter [13:49:24] Hey [14:52:37] hey indy91, I fixed my race-condition last night [14:53:12] and the zeroing [15:02:44] hey [15:02:49] great [15:04:56] haha, didn't think Guenter heard me last night. [15:05:08] there was one more thing that I didn't like, that I had forgotten to talk about [15:05:10] just a small one [15:05:15] sure [15:05:16] in RFCALC_rcvdPower [15:05:22] if (isnan(rcvdPower)) [15:05:36] isn't frequency being 0 the only condition that leads to that? [15:05:51] in that case we don't really need to catch the NaN [15:05:56] just if (frequency == 0.0) [15:06:39] oh yeah... [15:06:47] hmm well [15:06:50] distance == 0 [15:07:06] could get you a divide by 0 [15:07:11] yep, that would to it too... [15:07:17] which will not necessarily result in isnan catching it though [15:07:19] not sure [15:08:03] but isnan is probably most useful if we don't know the conditions leading to the NaN [15:08:09] so I don't think we need it here [15:08:21] so maybe just checks on distance and frequency being 0 [15:14:08] I wonder if it would be better to check if they're really small, like 1E-10. in case some weird floating point thing sends the function something that should be 0, but isnt exactly [15:14:36] would also catch negatives [15:14:47] which also wouldn't make sense [15:15:01] for distance that is a good idea [15:15:09] frequency will be 0 or something reasonable [15:23:37] yeah, that makes sense [16:40:48] everything with the RR is working great btw [16:40:51] transponder [16:41:13] signal strength volts in the LM [16:56:34] awesome [16:56:57] glad I didn't break that :) [16:58:32] you made it better [16:58:49] same with VHF ranging... when the next PR is merged :D [16:59:12] I was also impressed that I didn't break any old MCC calculations for Apollo 10 [16:59:29] I hadn't done any Apollo 10 specific work in a while, but a lot of low level calculations changed [16:59:53] well until I saw one thing that was broken [16:59:59] but it wasn't so bad [17:00:21] just failed to calculate the TPI time for the CSM backup insertion maneuver, which isn't normally done anyway [17:00:51] a RTCC function I implemented couldn't deal with the very elliptical orbit of that rendezvous profile where the LM can't do the insertion maneuver [17:01:56] and it wasn't even a catastrophic error where the MCC can't proceed, just had the time as all zeros [17:02:41] but I am not done yet with the rendezvous, still a chance of more problems [17:27:40] hmm [17:27:49] did I speak to soon for the RR [17:27:57] too* [17:28:08] I had a scenario saved where it had locked on [17:28:30] when I loaded the scenario it had to go through the acquisition again [17:33:36] odd [17:34:04] thought I fixed that [17:36:20] I'll load the scenario again, maybe it's something else [17:37:58] oh had you also done some changes to the RR self test? [17:38:14] just seeing the code for it, hadn't noticed that changed [18:06:17] hmm [18:06:29] I hate to say it, but I think RNDZXPDRSystem::GetCSMGain is also not calculating everything correctly [18:08:00] degrees vs. radians issue [18:21:01] I can believe the deg/rad issue. I just fixed one like that in the HGA code [18:21:35] and yes, I added functionality forhe self-test gauge with the RRT [18:21:49] *for the [18:22:36] does the state of the lock timer get saved. maybe that's what's breaking the lock [18:24:05] no I meant the RR self test, not RRT [18:24:24] square wavew [18:24:26] wave* [18:24:48] lock timer in RNDZXPDRSystem gets saved [18:25:33] so does RangeLockTimer in LEM_RR [18:28:46] I want to get to the point of saving the pre insertion maneuver scenario, then I'll go back and look at the scenario again where I should have had lock [18:43:49] Apollo 10 LM staging, what could go wrong... [18:59:25] morning! [19:06:29] as long as you don't have any gyro transients you should be fine :P [19:08:51] ha, staging didn't actually work [19:08:58] can't have problems staging if you don't stage [19:09:21] I had accidentally opened one of the ED logic power circuit breakers [19:09:29] staging needs both [19:10:31] n7275, sadly I have to confirm, in the saved scenario it was locked on, no problem [19:10:46] when I loaded the scenario it was initially at 0 and then locked on again [19:10:49] hahaha [19:12:07] indy91, speaking of staging... I finally figured out what the Luminary 99 bug is and what causes it :D [19:12:31] awesome [19:12:47] it's a very fun one [19:13:27] easy to replicate? [19:13:55] https://photos.app.goo.gl/RnveQtsEJFgCwtmj9 [19:14:00] ehhh sort of? [19:14:31] basically with Luminary 99 there's some small chance that if you hit the ABORT or ABORT STAGE button, the computer restarts but nothing happens for 163 seconds [19:15:19] and it's triggered if another waitlist task is scheduled for the same time (or maaaaybe 1cs after) the R10,R11 task that detects the button is down [19:15:42] so not a high probability [19:15:58] in that case the restarts routine doesn't actually set the TIME3 timer for the servicer [19:16:00] yeah [19:16:14] however, I think I have a procedure that will make it a 100% probability [19:17:20] ah, would love to try it in NASSP [19:17:51] V21 N01 E 1371 E 34753 E [19:17:51] N15 E 05173 E E [19:17:52] 01371 E E [19:17:53] 05261 E [19:17:53] V25 N26 E [19:17:54] 1 E [19:17:55] 1371 E [19:17:55] 0 E [19:17:56] V31 E [19:18:02] to be done probably prior to entering P63 [19:18:31] that makes a tiny 4-instruction EMP that gets scheduled for the waitlist every single centisecond [19:18:40] and guarantees you will have a scheduling collision there [19:19:29] I haven't tried it in NASSP myself yet but the EMP at least works in standalone virtualagc :) [19:19:40] LMY99R0 [19:19:43] yep [19:22:49] hopefully that's not too much additional load for the P60s [19:24:15] if it is I'll have to think more... R10,R11 runs once every 250ms so really I guess any particular waitlist task has a 1 in 25 chance of coinciding with it, and then your button press needs to coincide with that [19:27:01] I wonder how they found that bug [19:27:38] it might have just been random chance in some test they were running [19:27:50] they hit the button and N63 didn't come up lol [19:29:00] I like their workaround of V69E [19:29:05] nice big hammer to fix the problem :D [19:30:26] haha yeah [19:30:51] does this have an anomaly number? [19:30:55] LNY-77 [19:31:10] "No takeover when Abort from P60's" [19:31:16] ok, I'll save a scenario at T-1min with that name [19:33:06] actually hmmmm.... [19:33:29] slight modification to the procedure: it might be better to only do the V31E at the end after R10,R11 has started [19:33:37] so once you're actually in powered descent [19:34:27] too late haha [19:34:33] if it doesn't work I'll try again [19:34:44] so just abort or abort stage button any time during the descent [19:36:02] why does it say "N63 doesn't come up" if N63 is already up in P63 [19:36:41] going into P70 or P71 via the abort buttons actually causes a full computer restart [19:37:05] it sets up the phase tables beforehand to start up servicer, GOABORT, and some other things [19:37:22] so even if it's up in P63, it won't come back [19:37:36] well it did come back [19:37:58] so on the next attempt, same procedure, entering that EMP before P63 [19:38:12] V31E after throttle down or so [19:38:41] another way to see for sure if it triggered would be to do V01N01 E 26 E [19:38:57] 37767 [19:38:59] we're looking for TIME3 to be a small-ish positive number [19:39:06] that is much too large haha [19:39:29] well I know that navigation and guidance worked because P70 took me back to a good orbit [19:40:32] lol and then, because I just had descent engine command override on, it just continued firing the DPS at 10% thrust [19:40:40] still had* [19:41:06] hahaha [19:41:34] which is probably correct behavior [19:41:59] yeah I think the only way to stop the engine is by pushing the engine stop button [19:42:17] will try again in a bit [19:49:06] need to review waitlist code, but I think starting the EMP before R10,R11 meant that it was always going to run before instead of after it in any given T3RUPT [20:01:07] but I can do the V25 N26 before P63, right? [20:01:23] I can do the whole thing after throttle up, wouldn't be a problem [20:03:00] yep [20:03:12] everything before the V31 is setup that you can do whenever [20:03:34] also hold on, I need to test the EMP in standalone, I might only be scheduling it for 50% of the possible cycles [20:06:53] hmmm no that should do it [20:07:54] if the EMP is working, V01 N01 E 26 E should never show you anything other than 37777 [20:08:42] looks very large for a small-ish positive number [20:08:58] lol well the EMP dies with the computer restart :P [20:09:11] I meant before you hit the abort button lol [20:10:16] right, between V31 and abort [20:12:32] V31 caused a restart [20:13:06] V01 N01E 26E shows 37754 [20:13:51] and the anomaly didn't happen sadly [20:15:01] restart really? [20:15:18] hmmm [20:15:19] maybe I did it wrong [20:16:36] https://i.imgur.com/HmCj9LG.gif [20:16:38] something overwrote EMEM1371 [20:16:56] a restart will do that [20:17:11] hmmm but I thought only self check wrote there normally [20:17:19] this is in my T-1min scenario I saved [20:17:35] scenario was in P63. I got to P00, enter the EMP [20:17:39] then go to P63 [20:17:48] and P63 must have overwritten it [20:18:20] hmm very weird [20:18:22] well we can move it [20:18:29] EMEM1371 3337 [20:18:29] EMEM1372 5173 [20:18:30] EMEM1373 1371 [20:18:31] EMEM1374 5261 [20:18:35] the rest looks good [20:18:38] it just needs 4 contiguous erasables that aren't used in the landing [20:18:49] maybe we shift up by one to start at 1372 then? [20:19:03] and the 01371 in the EMP itself also becomes 01372 [20:20:34] or I edit the scenario [20:20:50] and make it 34753 again [20:20:55] haha [20:22:24] but it is quite strange [20:22:29] what would overwrite it [20:22:38] I don't know, I really thought only self-check would [20:23:57] hmmmm maybe the idle job does [20:24:07] ...yeah it's probably better to start it at 1372 [20:25:04] it actually had the same value already before I entered the EMP [20:25:15] I am 99.9% sure I entered a value [20:25:37] yeah that's a return [20:25:45] SELFCHK does a QXCH SKEEP1 [20:26:16] even in idle potentially [20:26:23] so that address isn't safe [20:26:31] ok [20:26:49] yeah calling P63 has already overwritten it [20:27:27] maybe it still works in the edited scenario [20:27:31] if not I'll try with 1372 [20:27:37] so same procedure, just all three 1371s replaced with 1372s [20:28:48] hasn't been overwritten yet [20:29:40] seems ok after throttle up [20:30:01] I'm stupid [20:30:08] did abort without V31 :D [20:30:12] back to T-1min [20:31:10] hahahaha [20:32:38] yeah looking at the waitlist code, if we can get this EMP to trigger on the same T3RUPT but after R10,R11, the bug should trigger [20:33:36] because TIME3 will overflow in the calculation but the T3RUPT code won't do anything about it because it assumes that you'll be going back to it with TASKOVER instead of triggering a restart with ENEMA [20:34:33] you gave me the wrong EMP [20:34:43] this one produces 1202 alarms :D [20:34:50] and lengthy DSKY lockups [20:36:53] hmm [20:36:58] now it's completely locked up [20:37:05] doesn't even give program alarms anymore [20:37:09] just the static display [20:37:18] should it switch to P70 if the bug is happening? [20:37:26] displayed P70 I mean [20:37:48] might have been the bug [20:37:53] V69E fixed it [20:38:08] went to P70 at that moment [20:41:48] hahahaha [20:42:08] damn, so just the EMP running casuses 1202s? [20:42:32] actually one 1202 would be enough to stop the EMP running I think... [20:42:32] yeah, seems like it [20:42:37] okay damn [20:42:42] apparently I need to be more clever [20:42:48] I entered it again though [20:42:52] after fixing EMEM1371 [20:43:00] so maybe this was the bug I got then? [20:43:07] DSKY didn't change at all [20:43:11] stuck showing p63 [20:43:17] no N63 updates [20:43:22] no program alarms, restarts [20:43:23] nothing [20:43:30] not until I did V69 [20:43:34] after hitting abort/abort stage? [20:43:38] yes [20:43:43] yeah that sounds like it :D [20:44:14] it would have started back up if you waited 163 seconds [20:44:42] pretty sure navigation and guidance was completely broken though, even afterwards [20:44:50] it impacted the Moon [20:45:01] after it thought P70 got it back up to orbit [20:46:05] oh yeah, as they mention in that program note, guidance is not operating at all [20:46:12] so no state vector updating or anything is going on [20:46:37] definitely more than the 5 ft/s radial navigation error it talks about though [20:46:38] the longer you leave it before the V69 the worse it gets [20:46:51] ah ok [20:46:56] yeah that probably explains it then [20:47:11] so I guess I got the bug, although not quite as I thought [20:47:33] due to overloading the computer with the EMP [20:47:37] yeah [20:48:12] I can write a slightly larger EMP that attempts to synchronize itself with R10,R11 [20:48:25] what is the biggest safe chunk of unused erasables for descent? [20:50:19] I only know padloads [20:50:45] if we don't want to test this with P64 you could overwrite P64 padloads :D [20:50:54] haha [20:51:09] about the V25 N26 [20:51:16] where does that get stored? [20:51:54] you could also overwrite [20:51:55] # W-MATRIX. ESSENTIALLY UNSHARABLE. (162D) [20:52:06] hah [20:53:18] hmmmm [20:53:57] oh no [20:53:58] haha [20:54:09] I forgot the first rule of powered descent [20:54:19] don't do P20 marks before descent [20:54:22] lol [20:54:27] or else the W-Matrix overwrites all of the descent targets [20:54:35] ooof yeah that is not great :D [20:54:38] so W-Matrix is very bad [20:55:12] ....uhhh N26 might just use DSPTEM1... in which case there's potentially several things that could overwrite it [20:55:47] like a please perform [20:55:55] ...maybe it's not safe to separate that from the V31 [20:56:01] oh [20:56:21] I knew it was DSPTEM1, but thought it would store that somewhere else as well [20:56:32] I thought so too but I'm not finding it [20:56:35] isn't there special V25 N26 logic? [20:57:02] I'll try it again with the V25 N26 after throttle up [20:57:11] EXTEND [20:57:11] DCA DSPTEM1 +1 # JOB ADRES INTO MPAC+1 [20:57:12] DXCH MPAC +1 # BBCON INTO MPAC+2 [20:57:17] that's the V31 code [20:57:22] seemingly loading straight from DSPTEM1 [20:57:39] huh [20:57:49] so you really can't do anything in between with EMPs [20:57:58] yeah [20:58:00] I did not know that [20:58:17] but having N63 up doesn't hurt, right? [20:58:26] or is that already overwriting it [20:58:27] no, it shouldn't [20:59:06] same result [20:59:17] DSKY locks up, 1202 alarm [20:59:35] man I really didn't think this would be *that* much extra load [21:00:31] so ideally the EMP would synchronize itself with R10,R11 and run every 250ms alongside it [21:00:34] that would be almost no extra load [21:00:40] but how to most efficiently do that... [21:08:29] I guess I could have it check like every 10cs or something if R10,R11 is the next task, and if so, schedule it for the same time [21:10:58] hmmmmmm [21:15:44] this is unfortunate [21:15:49] I need to think on this more lol [21:27:04] I think I have an EMP that might do it in.... 15 words [21:27:09] just a little bit bigger than the 4 before [21:45:16] oohhh actually we might be able to trick the waitlist with one V01N01 [21:45:20] into synchronizing them [21:50:59] night!