[08:29:37] NASSP Logging has been started by thewonderidiot [08:29:41] Guenter! [16:40:17] hey [16:50:13] hey [16:59:31] hey [17:03:26] hey Alex [17:04:01] got it working, letting the RTCC MFD use the RTCC instance in the MCC [17:04:09] now I need to figure out if this is a good idea lol [17:06:55] nice [17:08:02] I guess it could be bad for MCC scenarios? [17:09:29] MCC and RTCC MFD can mess with each other yeah [17:09:54] but it should be fine, you reallyl have to sabotage yourself for it to make a difference [17:10:30] right [17:11:43] so would the MCC vessel now be in all scenarios? [17:11:57] yes, and if it doesn't exist, the RTCC MFD creates one [17:12:17] makes sense [17:12:24] there will be a lot more save paramaters [17:12:34] the RTCC save function only saved stuff relevant for the MCC so far [17:12:52] but that becomes necessary anyway, if I want to use the "new" TLMCC targeting for the MCC [17:12:57] which it still doesn't use [17:13:53] would routing the RTCC MFD uplinks through the MCC menu uplinks function still be on the table? [17:14:42] hmm, don't really remember what that idea was [17:14:52] what's the advantage? [17:21:45] hmm, I think a few weeks ago we spoke about it briefly when talking about adding some MFDs to the MCC vessel to simulate mission control [17:22:54] I mean, I could set it up so that the MFD uses the MCC uplink interface [17:23:03] would mess even more with the MCC of course [17:23:07] like preparing an uplink from the MCC vessel, then when switching back to the CSM/LM, you dont have to open and MFD, just use the TAB menu to uplink [17:23:26] but its not that important right now I guess [17:23:44] could definitely work [17:29:22] I made the RTCC MFD uplink interface work like the PAMFD one when I first implemented it [17:29:34] but it could instead use the MCC one [17:29:55] does the MCC have a way to "know" when its in "MCC" mode (automatic pads/uplinks) and non-MCC mode other then disabling/enabling mission tracking? [17:30:23] not right now [17:30:52] maybe that could be added and then the RTCC MFD uplinks to it checks that condition? [17:32:12] for what purpose? [17:35:48] what would/should be different for the RTCC MFD? [17:36:14] so that you cant manually uplink from the RTCC MFD using the MCC menu during the MCC missions [17:36:59] so basically preventing that the RTCC MFD overwrites a MCC generated uplink [17:37:49] yeah, I guess [17:37:57] as you said, to not mess with it [17:38:54] I mean, I could make it check if mission tracking is on [17:39:39] I'll look a bit into how the RTCC actually generated uplinks [17:40:39] well I know they were C-type MED codes [17:40:56] but that basically just generated an uplink [17:41:16] what really initiated the uplink I'm not quite sure yet [17:41:26] have to listen to a few more MOCR loops [17:46:36] right [17:47:23] I guess I was also thinking about making the TAB menu more involved in general, as an interface between MCC and spacecraft [17:48:33] like if you are eventually using MFDs in the MCC vessel to calculate a maneuver/uplink, you wouldn't need to open an MFD again in the spacecraft to initiate the uplink [17:49:29] yeah [17:49:36] but I guess not everyone is going to want to be that hardcore to actually switch to the MCC vessel and back to calculate stuff :D [17:49:40] morning! [17:50:06] hey Mike [17:50:39] the reason I had started thinking of that is with the VC, since you already have to switch to the 2D panel to access an MFD, why not switch to the MCC vessel [17:50:40] so just before Apollo 11 Earth orbit state vector uplink GUIDO asks "Command" to generate a CSM nav update for the CMC [17:50:47] hey [17:54:17] could the flight controllers stop talking over each other, thanks [18:11:56] computer command controller is the one that is transferring uplinks to the stations [18:26:27] the "realistic way" would be to generate a command load, which then gets assigned a load number [18:27:03] and in the CAPCOM menu you typein that number [18:27:22] the question is how large of a backlog it keeps [18:27:41] ah, I think I know, it doesn't have a central place to store uplinks [18:28:06] it's more like [18:28:15] one CMC state vector uplink, one LGC state vector uplink etc. [18:29:32] I have to decipher the system of load numbers :D [18:29:46] 0002 is the CSM state vector uplink from Earth orbit [18:30:02] but there is stuff like 5808 [18:36:31] I cracked the code I think [18:36:38] first two digits are the same as MED code [18:37:01] there is a load number 1201 on day 1 of Apollo 13 [18:37:04] C12 is REFSMMAT [18:37:08] so that's the PTC REFSMMAT [18:37:16] second day has a 1001 [18:37:30] C10, External DV update [18:37:34] that's MCC-2 [18:39:05] does that sound like a good system? The display for an uplink shows the load number and you need to type in that number in the CAPCOM menu for an uplink from the RTCC MFD [18:39:26] that way you can generate a bunch of uplinks in advance [18:39:31] and then uplink them [18:40:36] sure [18:41:55] I think we should also make the "voice check" function of the CAPCOM menu use the new comms features recently added [18:42:14] just like simply give a reply if there is a good signal [19:00:21] oh hey. Alex you had asked me about that a few weeks ago [19:07:37] I think I'd started to look at it right about the time I got distracted by fuel cells... [19:13:40] haha no worries [19:14:02] just an idea I had [19:26:18] it's still on my list :) [19:55:52] I take it there haven't been any sightings of Ryan since the other day? [20:06:11] nope [21:42:47] Hey all, [21:45:16] got the LM working under Vesim control. Added tons of buttons so I can do a PDI without touching the keyboard too much. Combining it with the VC it is really fun! [21:45:48] hey [21:45:52] awesome [21:46:07] I have played around with it, but I couldn't figure out the exact name of my controller [21:46:15] so custom controller file didn't work [21:46:34] the default one had the right axes for the RHC though, so that worked at least [21:46:42] CM - GenericJoystick.launchpad.cfg [21:46:48] yeah [21:47:01] I guess I could have modified that one lol [21:47:11] instead of making a new file for my own controller [21:48:32] Other solution is the compile it in debug mode, then Vesim logs the file names it searches for. Vesim.log in main Orbiter folder [21:48:48] ah right [21:50:45] I think the next step is to make the configurator for Vesim, to avoid all this mess with joystick names and tab delimited files. [21:51:48] sounds great to me lol [21:53:15] one thing I have to try again, but with the RHC I had the RCS firing if the analog stick was just slightly out of the center [21:53:31] might be normal with the controller [21:54:22] but I feel like it shouldn't do that so soon, was it maybe doing only 0 and 100% deflection? [21:54:49] Do you get the same with normal joystick settings? [21:55:09] will try [21:55:13] in a moment [21:56:06] Theoretically Vesim reads the same values as the original joystick driver, and all deadband issues is handled by NASSP itself. [22:02:41] What we can do here is to add to Vesim an additional configurable device axis parameter, which is the deadband itself. So for noisy controllers, slightly off-center measurements will be reported to NASSP as centered positions. [22:06:47] ok, I think it was indeed a not very centered analog stick [22:07:05] RHC breakout switches are switching very early [22:07:30] 1.5° deflection out of 11.5° total [22:09:35] let's see if I can find out the name of my joystick... [22:09:44] Xbox 360 Controller I mean [22:10:18] my joystick is a Microsoft Sidewinder Force Feedback 2, now that is a file name [22:11:35] Found stick instance: Controller (Xbox 360 Wireless Receiver for Windows) Prod name: Controller (Xbox 360 Wireless Receiver for Windows) [22:11:48] so file name [22:11:49] Xbox 360 Wireless Receiver for Windows [22:11:49] ? [22:12:09] CM - Microsoft Sidewinder Force Feedback 2.launchpad.cfg what you need then for the Sidewinder [22:12:21] right, haven't tried that one yet [22:12:50] And I use the product name, so I think you are right fro the Xbox ctrl [22:13:39] wait, CM or CSM? ANd what's with the "launchpad"? [22:14:39] Sorry, CSM. I mean "CSM - Xbox 360 Wireless Receiver for Windows.launchpad.cfg" and "CM - Microsoft Sidewinder Force Feedback 2.launchpad.cfg" [22:14:57] "CSM - Microsoft Sidewinder Force Feedback 2.launchpad.cfg" [22:15:09] is that a new change? the VKBsim Gladiator file doen't have the "launchpad" [22:15:27] and do I need the empty space before ".cfg"? [22:17:51] The VKB stick reports it's name with the space (I guess it is because somebody not payed attention very well at VKB). If you not seeing space in the reported name, you don't need it. [22:18:01] ok [22:18:19] I see the launchpad in your VESIM manual [22:19:16] launchpad files are the user config files (excluded from source control). So personal preferences is better to go there. However there isn't any difference for Vesim between the .cfg and .launchpad.cfg files. [22:22:29] ah ok [22:26:54] still not working, have to use all the debugging lines [22:30:12] oh [22:30:14] haha [22:30:16] Attempting to open file Config\ProjectApollo\Vesim\CSM - Controller (Xbox 360 Wireless Receiver for Windows).cfg [22:30:23] so I have to name it that lol [22:31:51] Hope that it is possible to create files with parenthesis in their name :) [22:31:58] it is [22:33:38] hmm [22:33:44] I think it reads the right file now [22:33:53] but the THC is still not working as I wanted to configure it [22:34:03] Cfg Line:THC X Axis Button 12 FALSE [22:34:03] Connection for input "THC X" is defined as device 0 (Controller (Xbox 360 Wireless Receiver for Windows)) subdev type:2 subdevid:12 reverse:0 [22:34:04] Input 3 (THC X) connected to device 0 (Controller (Xbox 360 Wireless Receiver for Windows)) subdev type:2 subdevid:12 reverse:0 [22:34:17] looks like it's doing the right things though [22:35:00] Yes it was able to connect button 12 to THC +X [22:35:40] oh [22:35:44] something is working [22:35:48] You will need a -X button as well, however it should work with only one button (you can accelerate forward only) [22:36:02] I had Orbiter in attitude mode translation [22:36:19] then it uses the RHC axes in VESIM mode it seems [22:36:59] two buttons are working [22:37:03] the DPAD is not working [22:38:13] Use it in rotation mode. If you map separate subdevices to RHC and THC, it will work only if you are continuously in Rotational mode. [22:38:27] yeah [22:38:37] in translation mode the RHC controls act as the THC [22:38:46] in rotation mode I have two buttons working [22:39:05] the online tool you linked me treats the DPad as buttons [22:39:15] maybe VESIM seems them as axes or so? [22:39:19] sees* [22:40:42] maybe POV switch which is behaving differently as axes and buttons, but it detected as axis by the gamepad tester [22:40:59] Do you see in the log file it is mapped correctly? [22:41:05] I think so [22:42:03] Do you want to map it to THC Z and Y? [22:42:26] yeah [22:43:50] two normal buttons as THC X is working [22:44:08] could it be detected as RY and RZ? [22:44:16] Hey [22:44:21] how do I set that up, do I only need one line for THC Y and Z each? [22:44:24] hey Thymo [22:44:43] What's up? [22:44:46] Hi [22:44:58] testing ggalfi's joystick tool [22:46:49] If it is POV axis, it isn't yet supported (POV axes are returning continuous values but in a different way as normal axes). But if it is detected as button by gamepad tester, it is a little bit different situation, it ought to be working. [22:47:39] well, the gamepad tester shows XInput [22:47:45] we are using DirectInput though [22:48:14] doesn't work as axes either, so I bet it's treated as a POV [22:50:29] In the game tester page you see it neither B (like B 12) nor AXIS ? [22:50:49] I see it as buttons 12 to 15 [22:51:31] but when I use those with VESIM it doesn't work [22:53:12] but then it shows the left and right trigger as buttons 6 to 7 [22:53:17] so maybe that's misleading [22:55:03] There is an other option: in Win7 (what I use) there is a controller setup tool. I should just type in the search window "joystick" it come up. That is also displays the button and axis states. [22:55:21] Surely it exists in Win 10 as well [22:55:58] Hopefully it is based on DirectInput [22:56:15] aha! [22:56:20] it's POV [22:56:45] so that's the issue with the D-Pad then [22:56:52] Could you test temporarly it with "normal" buttons? Seem to me I have to put this POV thing on the top of the TODO list. The kids have gone already to bed, so I can aquire the Xbox ctrl. [22:57:05] it works with other buttons [22:57:18] not the triggers, but the bumpers and any other normal buttons [22:57:46] triggers are some axes, or sliders [22:58:40] Yes, but either sliders or axis should work (use Slider 0 or Axis RX or something like this) [22:58:45] yeah [22:59:24] Feel free to map an axis to a button input [23:00:11] Just take care if the "pushed" state is corresponding to a minimal value, you should set reverse=TRUE [23:00:25] yeah, that all seems to work fine [23:00:46] on this controller though the D-Pad is definitely the best choice for 2 of the 3 THC axes [23:00:53] so would be great if that could be supported [23:01:13] I guess alternatively [23:01:23] left analog stick and the two triggers as RHC [23:01:31] LB and RB and the other analog stick as THC [23:03:48] Yeah both sounds good. That is the goal here to let the users to find the most convenient or ergonomical settings. [23:04:08] just tried it with that setup, works well [23:04:17] most importantly, it works haha [23:05:31] Thymo, I wanted to ask you something [23:05:59] most of our VS project are build with runtime library /MT [23:06:04] multi thread [23:06:08] and /MTd in debugging mode [23:06:31] RTCC MFD is /MD for some reason, but that could be changed [23:06:33] but [23:06:48] I had a bug with ostream, specifically the << operator [23:07:23] with an instance of the RTCC class, owned by the MCC (in the MCC module) called by the RTCC MFD (RTCC MFD module) [23:07:44] and I googled a bit around and the only way it works is if both modules are build with /MD (or /MDd) [23:08:06] I don't really know which is better, but I might want to permanently change MCC to /MD [23:08:29] any potential problems? Should all projects be /MD? [23:09:48] you can think about that for a few hours, I'll go to bet [23:09:50] bed [23:10:10] ggalfi, great work, looking forward to merging it in the not too far future [23:10:14] good night! [23:19:28] .tell indy91 MD is dynamically linked while MT is static. No idea why we use MT across everything, MD is even the default I think. If we use MD it should reduce RAM usage and DLL size as well. What you suffered was an issue caused by using different versions of the module since one was linked dynamically and probably more up to date and the other was static. [00:34:35] .tell indy91 Looked into it a bit more, we can't switch to MD. OrbiterSound staically links the C runtime and since we staically link OrbiterSound we must also statically link MSCVR othwerwise the linker doesn't know which one to use. [03:37:28] ahh, gotta love those, "that's not *the* problem, but it is *a* problem" moments [12:26:39] Hey [12:50:10] hey Thymo [12:50:31] hmm [12:50:48] Do you think I can change the MCC project to MD? [12:51:11] or is any mix causing problems and I should also change the RTCC MFD to MT [12:51:28] it's not like the MCC needs Orbiter Sound [12:54:37] Yeah I tried, should work [12:54:51] It does include soundlib though, couldn't figure out why [12:56:13] there are some possible build errors caused by not including that [12:56:24] due to a bad include order in other files [12:57:25] Yeah when I removed it I got errors in apolloguidance. That isnt even related to MCC [12:59:39] you can go insane following the trail of includes [12:59:53] I improve this some years ago, but still a lot of problems [12:59:59] improved* [13:00:18] a lot of it is caused by saturn.h being so massive [14:02:50] hi [14:04:24] indy, you may use your DPad with vesim. I've made it to support POV-hats. [14:15:05] ah great [14:17:36] You should put something like this "THC Z Axis POV 0V FALSE" into your config file. [14:17:51] and only one line for each axis [14:18:00] not two, that's for buttons [14:18:57] Yes, I have converted POV data into axis data.So you need only one line. [14:20:29] I think except for maybe a better interface to assign buttons etc. and controllers the CSM should be properly covered now [14:20:33] let me look at the LM [14:20:42] ACA should be fairly easy [14:20:57] TTCA is always tricky... [14:26:00] ok, VESIM basically uses the "non realistic" TTCA mode, where the throttle lever is always separate from the TTCA axis that is used for the throttle, if the lever is in throttle mode [14:26:33] the "realistic" mode is definitely awkward to use anyway [14:26:47] nobody has a joystick or controller that really works like a TTCA [14:29:22] I have to read the op handbook :) I've just simply used the logic what the normal joystick driver employed. [14:29:50] well there is ttca_realistic_throttle [14:30:25] in the old joystick code, if the joystick assigned to the TTCA has a lever, that lever is used as the throttle/jets select lever [14:31:18] and the X-axis of the joystick is then either translation control or throttle control [14:31:40] but the real TTCA changes behavior for that axis if you switch between the modes [14:31:46] I see. [14:34:22] figure 2.1-42 is quite good to visualize this [14:34:26] in the AOH [14:34:27] for LM-10 [14:34:31] PDF page 169 [14:35:37] the closest you are probably going to get to the real TTCA behavior is with two levers on a joystick [14:35:44] one for the jet/throttle selection [14:35:53] and the other for the x-axis of the TTCA [14:37:19] it's fine not to support this. But you could add a flag in the VESIM config file to switch to that "realistic" mode [14:42:25] I understand now. I've always thought that the lever on the side of the TTCA is the throttle. But it is just selects between jets and throttle mode isn't it? And in jet mode it makes the TTCA X axis springloaded? [14:42:44] yeah, that's basically how it works [14:42:50] and I had the same confusion at first haha [14:43:01] it's an obvious error to make [14:43:08] I see lever, I think throttle [14:44:17] :) Would be nice to have a real TTCA device in my hands. [14:44:35] I'm sure there have been auctions for them [14:44:50] but after you bought one, you own one house less [14:46:43] Yes, that neat little gadget would cost much more than a whole flightworthy Cessna 152 [14:49:50] Ok, I'll make this configurable in Vesim. [14:50:33] it's been a bit of a brain twister when I implemented it, because there is a variety of different modes to consider [14:50:51] hmm [14:51:08] does VESIM right now support a mix of joystick and keyboard? [14:51:12] hadn't actually tried that [14:51:29] I think a fairly common use case is: joystick as RHC, Numpad as THC [14:51:46] and for the LM, joystick as ACA plus throttle lever, Numpad as TTCA [14:56:47] No, keyboard is not supported yet. But it is obviously something what I intend to put in the code. Previously, when I used joystick, I used it with the RHC/THC switching option, never came into my mind to use simultaneously keyboard and stick for conrol. [14:59:20] it's definitely what I usually use, when I have the joystick connected [14:59:56] which doesn't happen that often, I tend to do a lot of RTCC, LVDC etc. development where I don't do much flying. If I go through a full mission, then I definitely use the joystick [15:00:31] but not really the Xbox controller in addition to that, Numpad seems good enough usually for the THC [15:01:51] It won't be too complicated to include keyboard it as well. Just have to take care of disabling the normal keyboard handling when Vesim is enabled. Do you know any keyboard interaction which happens outside of clbkConsumeBufferedKey functions? [15:03:51] Or it could be a temporary solution to allow only the RHC/THC to bind to the keyboard through Vesim, and leave the other keyboard stuff intact. [15:07:44] I think it's all in clbkConsumeBufferedKey [15:08:25] But I think you have encountered a common problem when developing for NASSP, especially when replacing a system with a new one [15:08:40] Even the older implementation usually has many, many features [15:08:53] and it's very difficult to take them all into account when developing something new [15:12:48] You are right, I think I will go for the temporary solution. [15:15:07] probably a more complex solution, but you could also make it per RHC/THC control [15:15:20] so if the control is left blank in the config file [15:15:24] no button or axis assigned [15:15:28] it would use the keyboard then [15:15:35] just an idea [15:36:37] That could work. Even better, Vesim inherently can handle this as a device is connected only to an input when it isn't blank in the config. And for an axis input, the last defined connection will be effective. So if there is a well defined axis-axis connection for THC, it will override the keyboard inputs, but if there isn't then keyboard keys will [15:36:38] be effective [16:37:45] hey [16:40:41] hi [18:26:21] hey Alex [18:32:30] trying to get the MCC and the RTCC MFD closer in how they use the RTCC class [18:32:38] old plane change targeting is no more [18:32:59] old LOI, DOI and MCC targeting all still exist, but I'm working on it [19:08:54] right [19:10:46] I'm actually testing if I can use the MED inputs for the MCC as well [19:11:00] will need a lot more save parameters though [19:11:30] but the way I set up the new LOI targeting uses a lot of these RTCC system parameters, so i kind of have to do that anyway [19:31:21] morning! [19:56:40] hey Mike [20:04:47] what's up? [20:17:54] make MCC stop using old RTCC code, delete same RTCC code [20:29:30] did you try any more Comanche 45? I haven't in the last week anymore... [20:33:34] nah I'm taking a bit of a break [20:33:49] can only throw yourself at a wall for so long in a row haha [20:34:48] I'm back to trying to finish punchcards for Aurora [20:34:54] now in the last large (32-page) section of it [20:49:16] I'll give it another shot soon, just needed some time away from it [20:50:19] same [21:06:58] I am really excited to finish off cards for Aurora [21:17:16] yeah, been a long project already [21:28:15] yeah [21:28:23] Luminary 69 is going to take forever lol [21:28:32] but then the rest of the Luminaries will be fast [22:07:47] night! [22:24:00] hey guys [22:24:21] yo [00:05:32] I've been thinking about numerical integration methods lately [00:07:44] not convinced we're stuck with Eüler [16:12:33] good morning [16:42:44] hey [16:46:16] thinking about the best way to make the MCC use the new TLI simulation [16:54:28] well, I'd like to get rid of the old TLI simulation, but even the RTCC MFD still uses it for the TLI PAD [17:22:43] maybe it's an easier task to first make the TLI PAD use the new function [17:30:54] morning! [18:24:24] hey [18:49:26] hey guys [18:58:06] good evening [00:37:31] I've added so many pipes now, things are starting to look like that old Windows screensaver [00:41:48] hehehe [01:05:38] these temperature transients, take 1-4 hours to stabilize, so getting the performance dialed in and on the ball to the datebook graphs could take a while [01:08:30] there are now all 8 radiators, with 3 coolant loops [04:15:46] Hey mike, had something odd happen earlier [04:16:52] was testing my eps cooling for stability at high time acceleration, ~50x, which is generally speeking, too fast for my computer [04:18:41] a few times, I got restart lights showing on the dsky, which definitely has happened to me before when pushing the timesteps this large [04:20:17] but on one of them, I switched back inside and had "Prog 59" showing [04:21:41] hah that's super weird [04:22:39] I wish I saved a copy of the memory [04:23:19] my best guess is that there's either some sort of memory corruption happening with multi-threading, or maybe high time acceleration is causing the computer to somehow skip instructions or something [04:25:19] yeah, gotta be something like that [04:28:18] I was 99% certian that wasn't a real program [04:45:04] might be a coincidence http://web.archive.org/web/20190707032450/http://nassp.sourceforge.net/wiki/Simple_AGC#Docked_Vessel_Control [04:45:24] but that's completely outside of even the emulation [04:46:56] and I can't even find any of that old code [04:48:02] haha, you're being haunted by the ghost of NASSP past :P [04:59:27] yeah, possibly, lol. the memory corruption/missed instruction thing seems more likely given that I can't find any of the old code here [05:00:38] I won't lose any sleep over it, but maybe Nik or Alex remember. I'll ask them tomorow when they're online [11:06:34] n7275: Yeah, known issue. It happens more often if you switch from high acceleration to low accelaration quickly. No idea what's going on with that, my guess is some issue with multithreading or something. [13:59:19] Thymo, I looked around for any old SimpleAGC code, but couldn't really find anything, at least not like it was. [14:01:02] SimpleAGC is completely unrelated to yaAGC, it was a C++ implementation from the days yaAGC was not in NASSP yet. We eventually removed it. The 59 you saw in the mode register was garbage data. [14:04:51] https://github.com/orbiternassp/NASSP/commit/a04b03a6b17c13b697a14d7238c10fe1b97f2db3 [14:29:36] okay. that's what I assumed, but it was an odd coincidence, and I wanted to check. [15:45:01] hey [15:47:33] lol, program 59 [15:50:52] fun fact, Skylark has programs 50 and 55, they have to do with the star tracker on the Skylab telescope [16:03:57] Hey [16:04:17] How did that work? Did the CSM provide attitude control? [16:07:13] hmm [16:08:23] I think P50 basically calculates a conversion between CSM navigation base and the ATM coordinate system [16:08:27] Apollo Telescope Mount [16:09:13] The ATM Star Tracker Gimbal Angle Program (P55) is used to compute and display [16:09:14] the gimbal angles for pointing the ATM star tracker at a designated celestial body. [16:09:32] The primary use of P55 output is input, in the event of star-tracker failure, for the [16:09:32] ATM digital computer. [16:10:13] and P51 and P52 actually have the ability to use a different source for data [16:10:23] a bit like with the AOT in the LM [16:10:35] so code 225 is detent 2, star 25 [16:10:40] in the LM [16:10:46] Did the ATM have an AGC then? I thibk it was a modified LM was it not? [16:10:52] it had a computer [16:10:55] not an AGC [16:11:21] Because otherwise you'd think they'd use Skylab's computer based on IBM System4/Pi for it [16:11:26] 0 = CSM sextant, 1 = sun sensor, 2 = star tracker [16:11:41] for the middle digit of the star code in P51/P52 of Skylark [16:12:08] not sure if the ATM had its own computer [16:12:13] it probably means the Skylab one [16:12:42] which is called ATMDC [16:13:05] Apollo Telescope Mount Digital Computer I guess [16:13:17] maybe that's the same thing, Skylab only had that computer [16:13:54] " Pointing was done with the help of the Skylab computer, which could be commanded from the space station by astronauts or by communication link from Earth." [16:14:02] According to Wikipedia [16:14:09] yeah [16:14:35] "The need for the computer system that served Skylab so well was not apparent until the original "wet workshop" concept (the laboratory to be assembled in space inside of the empty propellant tanks of the last stage of the launch vehicle) had progressed through more sophisticated designs to the eventual "dry workshop". In December 1968, NASA decided to acquire a dual computer system to help control attitude while in [16:14:35] orbit5. Attitude control was crucial to the success of the solar experiments. In fact, the name of the computer reflects this: Apollo Telescope Mount Digital Computer (ATMDC)." [16:17:14]