[22:39:25] NASSP Logging has been started by thewonderidiot [14:30:09] hey Niklas [14:30:46] hey [14:30:52] just trying to remember, for P57, is it the lower stars in the AOT FOV that will give best accuracy? [14:32:11] hmm, I don't really remember [14:38:11] the Apollo 11 lunar surface journal indicates that they used Navi, which is quite low in the AOT FOV [14:38:43] the alignment just after landing? [14:41:15] and I guess you mean close to the center of the AOT, right? [14:41:27] hmm [14:42:01] it's low in the right front detent and closer in the right reat detent [14:42:17] according to the preflight documentation, don't have Orbiter open [14:51:27] well the 2nd after landing, with the 2 stars [14:52:15] used Navi and Aldebaran, Angle diff was +00000 [14:52:23] haha, nice [14:52:37] I definetly notice lower diffs when using lower stars [14:54:00] lower over the horizon? [14:54:12] or far away from the center of the AOT view? [14:55:58] lower over the horizon [15:00:33] well, same thing really. All detents point up 45° so close to the horizon will be away from the center [15:07:27] but wouldnt a star near the top of the AOT give less accuracy for defining the yaw plane of the alignment (since the star is close to being on top of the LM) [15:08:50] I think distance between the two stars is more relevant [15:08:58] it's all vector math in thw AGC [15:08:59] the* [15:10:22] right [16:44:30] morning! [17:31:41] hey Mike [17:33:09] hey [17:33:12] what's up? [17:33:57] oh, nothing today really [17:34:03] and you? [17:34:37] fixed a subtle bug with erasable memory simulation last night that was causing restarts in some self-tests [17:35:25] restarts don't sound very subtle to me, haha [17:35:37] if a count happened immediately before an I/O instruction it would be considered part of the I/O instruction and the cycle would be allowed through... so some counts were being allowed through to "real" erasable [17:35:51] it was subtle because it would happen once every 20,000 self-tests or so :P [17:36:01] "some" [17:37:10] and that wouldn't happen with the normal erasable? [17:37:43] right, because in that case all the counts go to the right place [17:38:17] the problem here was that when trying to fully replace erasable, a few counts were being let through to the "real" erasable [17:38:31] oh, now I get it [17:38:33] i.e. they were being distributed between both [17:39:34] running the I/O self-test was able to cause the restart because the density of I/O instructions dramatically increased, to the point where sometimes the timers would not get enough counts to generate their interrupts on time, and I'd get a rupt lock restart [17:42:02] it was happening because counts don't change the contents of the SQ register, so the AGC still reports that it is executing an I/O instruction [17:42:52] sounds difficult to find [17:47:01] it was killing me on sunday when all I knew was that I was getting random restarts [17:47:16] once I figured out that some erasable writes were getting through it wasn't too hard to figure out why [17:47:52] yeah [23:53:25] SteveH: fixed a good bug in the monitor last night [23:53:56] it was a subtle thing that could cause a rupt lock restart once every ~10,000 in-out instruction self-tests [23:56:51] Dare I ask how you ever found it? By running more than 10,000 in-out instructions? [23:57:32] I first got a restart while running self-check option 10 (by total random luck) [23:58:03] and after I couldn't reproduce it I went through options 1, 2, 3, 4, etc. to figure out which one had done it [23:58:23] turns out option 2, the in-out test, which is fast so the AGC can run through a thousand or so per second [23:58:48] and it only happened when I had erasable memory simulation enabled [23:59:25] I hit my head against it for a while on Sunday and then last night I broke out SBE to my AGC board's debug connector [23:59:45] and sure enough, when running that test there were relatively infrequent erasable cycles making it through instead of being caught and simulated [00:00:23] I'm in the process over the next few evenings of adding chan12 and chan30 to my peripherals. Need these to run the sequence of discrete signals to make the AGC think that the IMU is up and running. [00:00:42] it turns out the problem was with counters; because the SQ register doesn't change when the AGC executes a count instruction, if a count happens immediately before an in-out instruction it will look like part of that in-out instruction [00:01:06] which I wasn't asserting MAMU for since I/O doesn't hit erasable [00:01:28] nice! is that mostly a harnessing problem? [00:01:32] Thinks like IMU power on and power on delay complete. As well as zero imu, enable error counters, enable coarse align. [00:02:38] It's harnessing (about 30 signals) plus coding up the fairly trivial PIC code to create a 16 bit input port and a 16 bit output port. [00:02:44] gotcha [00:02:46] did you see the CDU schematics? :D