[23:00:56] Meeting started by thymo [23:01:12] Meeting chairs are: indy91, thewonderidiot, rcflyinghokie [23:01:30] Uh oh [23:01:31] .topic LM Heat loads [23:01:46] Current subject: LM Heat loads, (set by Thymo) [23:02:40] Mmkay, time to see if I can figure out how to get into a state where I can bring up P63. (I assume I'll need to give the AGC some landing site coordinates, for one...) [23:03:26] And undocking might help too... [23:05:43] Back to the heat loads, I think you are right thewonderidiot, I can just simply calculate heat load by power consumption [23:05:52] Is there a known power usage in standby? [23:10:08] 0.5A times whatever the battery voltage is [23:10:53] You could do Heat(Voltage()*0.5). [23:11:11] Or whatever name ended up being used for that function. [23:13:45] All the heat loads I am using from the chart are assuming 28VDC [23:13:59] So perfect world 14W [23:14:38] sounds good to me [23:15:55] Ugh side note, the more and more I look at the CM ECS the more I want to rebuild it [23:16:40] I just fixed a conversion error in the direct O2 valve and because of the way the code has the o2 flow calculated, it measures a flow higher than actual [23:16:51] But I guess I will deal with that later [23:17:09] Probably after 8.0 release :P [23:17:21] hehehe [23:17:44] The LM is moving along well though [23:19:03] Now that HEATLOAD is a hydraulic function, it is just added to the system timestep [23:19:26] 9.0 will get some CSM love. We'll need to get the SIM BAY going if I'm right. [23:19:37] Yep [23:19:56] And when we push for 9 I will take what I learned for the LM ECS and start breaking the CSM [23:20:24] spontaneously combusting CMPs! [23:20:26] :P [23:20:30] Haha oh yes [23:20:37] Hey if I initialize the suit I am ok ;) [23:20:55] We had another problem like that when we tried adding the hatches and opening them [23:21:05] LM ECS tanks had NaN for energy [23:21:21] NASSP 11 will probably be SKYLAB. AAP might be with that, otherwise 12.0 [23:21:24] Because they werent initialized [23:21:51] What about 10? [23:21:56] we'll have to try to get Skylark out of Margaret for that ;) [23:22:02] LM Block 2 and EVA [23:22:33] thewonderidiot: Indeed. We've got until 2020. :P [23:22:45] I doubt she'll be around that long, unfortunately [23:23:33] Who knows. She's currently 81. [23:25:51] Well the nice thing about the LM is the stage is set to add EVA [23:26:18] Actually we will probably be adding an EVA button of some sort to disconnect the crew from Lm consumables [23:26:26] And not kill them [23:30:09] Also slap the VC and failures somewhere in there. [23:30:59] One thing in the roadmap is "Make MCC use natual-sounding phrases in messages" which I doubt will happen soon or is really any demand for. [23:31:21] Orbiter 2015 support is basically there. Some slight issues with the pad still. [23:32:25] Systems modelling to enable hardware breakage due to mismanagement is coming along nicely. New systems (and ones being overhauled) are detailed enough that adding support for breakage will be easy. [23:33:12] Random failures are sort of there. The C&W has a chance to fail (to often). Engine failures. [23:33:42] Oh and I did a little on the mismanagement already. Pull the plug on a timer and you've lost the track of time. :P [23:54:41] rcflyinghokie: /* ECS without killing the crew... */ if(!NASSP) {return;} if (suit_isol == suit_disc && cabin_press < 1.76 && PLSS) { goEVA(); } if (occupied && !helmet && suit_press < 1.76) { asphxiate(THIS); return("Do you know who Jim LeBlanc is?\n");} [23:56:31] Hehe [23:57:00] managed to get stuff in his stash again and he doesn't know what it is. [23:59:57] Looks like a merge leftover. git stash drop and done [00:00:07] Anyone remember what the LM docking angle is hardcoded as? [00:00:47] 0? Alex or Nik should know. [00:01:13] I never looked at the docking code. [01:07:41] I still have a "NO ATT" light, but I'll take the rough alignment. Now to bring up the AGS. :D [01:11:03] we haven't implemented AGC->AGS communication yet, so it still needs to be done manually [01:11:12] that should be coming in the short term though [01:11:28] rcflyinghokie is the resident AGS usage expert [01:12:01] flips AGS switch to STBY and waits for the case temp to come up. [01:12:13] Sorry was making dinner [01:12:16] Whats up? [01:12:49] haha nothing really, just blathering [01:13:00] Ah ok saw the chat window flashing [01:13:12] But yeah I got pretty good with the AGS :P [01:13:36] I think I am actually going to start there combining the heater for the AEA and ASA with the operation heat load [01:13:39] Make dinner, I'll wait. I'm bringing up an AGS. (The joys of simulated spaceflight: A pause button [01:13:42] Seems simpler than the IMU [01:14:01] Oh I am all done, cooked ate cleaned and now grabbing another beer :P [01:15:45] Scratch that, a whiskey :) [01:15:57] But yeah I got pretty proficient with the AGS [01:16:05] Especially after someone fixed it :) [01:17:08] lol [01:18:40] Which mission so I know which version of AGS [01:19:30] Got the master alarm all working as it should. Now it needs to be hooked up to the CWEA. [01:19:39] Which I will do another day. Goodnight! [01:19:42] Hmm, be nice if I had the AOF vol. 3 for LM-5. I have the one for LM-11+ [01:20:13] Current subject: General, (set by Thymo) [01:20:14] s/AOF/AOH [01:20:24] Yeah same with us [01:20:30] For the most part it is the same [01:20:48] I used it to supplement the LM 8 systems handbook when I did the LM ECS [01:21:48] And *damn* NASA for taking down the good parts of the NTRS [01:21:56] we kind of worked around that [01:22:29] a lot of the stuff that went missing was cached by archive.org's web scrapers, and the filenames have patterns [01:22:50] I wrote a python script to scrape areas around known good documents and pull down all located archived PDFs [01:23:05] so far there's only been a handful of things that we knew were there that we haven't been able to recover [01:23:49] our main source for new documents right now is the UHCL History Collection https://historycollection.jsc.nasa.gov/default.htm?CFID=3072753&CFTOKEN=13277169 [01:24:10] they got a whole bunch of stuff from MSC [01:24:24] ...speaking of which I'm supposed to request the Saturn V Systems Handbook [01:24:34] Ah yes its January [01:24:57] I'll request it tomorrow morning [01:27:23] But back to the AGS, Cannibal^ the only thing we cannot do with it yet is the PGNS/AGS updates so you will have to update the state vector for the CSM and LM manually [01:27:31] And its a pain for sure [01:27:39] coming soon to a LM near you [01:28:07] I know ECS took over but I am surprised on how fast it became stable [01:28:16] yeah you guys killed it [01:28:30] I never would have guessed it would already be working [01:28:40] I was the master of the config, Nik did the C++, and Alex hammered out the meshes [01:28:58] and I distracted people :P [01:29:01] Hahaha [01:29:25] Well now I need to get heat loads going otherwise the LM will be too cold [01:29:45] I need a minimum of I think 240W in order to run the sublimator [01:30:13] And of course without heating of the glycol, the suit temp would always be cold [01:58:42] Actually, I have an interesting question: Is landing via PGNCS possible without touching the AGS? (I know it's unrealistic, but I'm not really concerned with that: a PGNCS -> AGS link failure would've meant an increased likelihood that mission became a non-landing one.) [02:01:32] You mean if the AGS failed would it be allowed? [02:06:17] PGNS and AGS operational was a requirement for DOI and PDI for Apollo 11 [02:06:22] No, I know NASA would say "Enjoy the view, take pictures, jettison the LM, come back." What I'm asking is: If I started P63, could I make it to touchdown without getting aborted due to lack of an AGS [02:06:56] AGS is required through high gate [02:07:21] All the way through low gate [02:07:57] After hitting low gate if you lost AGS you would still be go I believe [02:08:52] But anywhere through PDI ignition and low gate if your AGS was INOP you would be told to abort I think [02:09:48] As in "Nice try, Please perform: do your job, monkey." hardware limitation? or "We monkeys here in Houston would prefer that you have AGS operational." policy limitation? [02:10:25] Policy, its in the mission rules verbatim [02:10:45] Loss of AGS proir to high gate is abort [02:10:52] after high gate its a continue [02:11:00] I guess it was safer to continue than abort that low [02:12:02] Yeah low gate looks like it is in late P64 [02:12:10] "Coffin corner": There are parts of the flight envelope where humans shouldn't be but you can still fly. [02:12:16] I guess you have manual control at low gate [02:13:20] So if I understand properly: nothing stops me from initiating the braking phase and landing without an operating AGS. [02:13:47] Other than a meat-space policy, that is. [02:17:36] Ohh yes [02:17:48] Well a few months ago we didnt even have the AGS working [02:17:54] Did all the landings with PGNS [02:18:28] And even in apollo 11, the PGNS was used the whole way, the AGS only used for reference, until Neil gimbal locked the PGNS when docking :P [02:19:12] I think I thought you were asking about the real mission rules and not the physical limitations haha [02:22:58] Oh, no I've seen a mision plan, I was more concerned with the physical ability. (You can operate a car without a muffler. If you're willing to suffer the wrath of the local government if they catch you, that is./You can land an LM without AGS. If you're willing to be grounded for life by NASA Administration, that is.) [02:24:09] s/a muffler/wearing a seatbelt [02:25:15] Better put, since the AGS is a safety feature. [02:25:25] Yeah pretty much [02:25:45] And since there is telemetry on WAY more than the crew can see, it isnt something they could hide [02:26:32] Got it. :D [02:26:51] However, you could land with just the PGNS no problem [02:27:03] Though it is cool to compare the two going down [02:27:23] I have done many AGS aborts now and its pretty crazy how close the PGNS and AGS are [02:30:18] ... Actually, I'm surprised PAMFD doesn't have a SV->AGS feature (Or does it?) [03:31:06] Sorry for the delay [03:31:15] Use RTCC MFD [03:31:25] It has an AGS SV option [03:31:31] Its not an uplink though [03:31:37] You have to type them in manually [03:48:20] Ah. [04:33:39] hah! [04:33:51] wait is this a transcription error [04:34:49] no [04:34:49] wow [04:35:23] so, you know how you know they never used the output counter EMSD? [04:35:34] every single program we have has it defined with the wrong address [04:37:50] EMSD is, according to the schematics, ND-1021042, and the Symbolic Listing Information, at address 052 [04:37:54] sorry, 056 [04:39:07] Colossus 237 and 249, Sunburst 37 and 120, Retread, Comanche 55, Aurora, and even SuperJob all have it defined as 055 [04:40:18] that is pretty bad [04:43:18] you would think that SuperJob at least would have it right since it was written at Raytheon [04:56:54] What was it supposed to do? [04:57:54] talk to the EMS in the CM, or a "LM monitor" in the LM [04:59:51] specifically to provide the EMS with velocity info [05:00:14] So it didn't suck so much? >:) [05:01:17] lol, I guess [05:16:10] reading ND-1021042, I'd *kill* for board shots of the logic trays. (And as someone who knows some of engineering, "when your change order proposals are able to be bound in a 400 page book, you have a big project. When those change orders are for a single device, you have a *massive* project.) I wonder if GM still has schematics. [05:19:25] yeah, I'm on the same page [05:20:01] the logic modules were all sort of uniformly laid out, with 2 boards each and 60 chips per board [05:20:16] and the schematics get us as far as knowing which gates were on which chip, and which pins were connected to which [05:21:22] I'm working on a database of interconnections right now, with the intent of trying to get physical access to one of the unpotted AGCs so I can beep out the things we don't know (main connector pinout, internal connector pinouts, core memory module pins, some other unlabeled pins, etc.) [05:22:04] Two books. (Good lord. Now I understand the reservations Wally Schirra had about Apollo 7) [05:22:12] lol [05:22:37] and Don's copy of ND-1021042 is even missing a good 100+ pages out of the middle, and doesn't have the supplement [05:23:35] (I would also kill for that supplement) [05:24:00] and proper schematics for all of the B tray modules.... [05:24:12] it's all gotta be out there somewhere, ready to be found [05:35:44] still... I'm really happy that Don had ND-1021042 [05:36:13] I had spent a solid couple of years searching all over the place for schematics of the B tray modules and DSKY [05:36:39] and then one morning just woke up to an email from Don saying he had dug this thing out of a box and if we would like to have it scanned [05:36:40] lol [06:11:31] Wait, B-tray is mostly core rope and core memory, right? So it'd be sense amplifiers, hand-woven core rope and core planes. ND1021042, vol 1 has B7 (oscillator module) at page 283 on the PDF. Betwen Volume 1 and Volume 2 there's a couple tidbits: Two erasable core modules with half of the erasable memory each, 64x32 core planes, stacked 16 deep. (It logically follows that each plane is actually [06:11:31] 32x32 cores, to give 1024 words per module, totaling the 2048 words of erasable. You're only missing B8, since drivers are just power supplies and sense amps are amplifiers and ADCs. I'll wager there was a lot of hand-tuning based on the on-hand component's performance particulars. [06:13:42] Crap, it's snowing again. I gotta go see if my washing machine's drain has frozen up. :/ (The joys of home ownership. yay...) [06:16:26] hopefully it hasn't! [06:17:28] there's only one erasable memory module that has all 2048 words (module B12), with planes of 64x32 [06:19:54] the modules are B1-B6 (fixed memory), B7 (oscillator), B8 (analog alarms), B9-B10 (erasable drivers), B11 (current switch), B12 (erasable memory), B13-B14 (sense amps), B15 (strand select), and B16-B17 (rope drivers) [06:20:11] ND-1021042 has relatively complete schematics of all of them [06:20:34] but sometimes it is lazy about labeling pins [06:21:51] all of the resistors they used for tuning are marked as such, although unfortunately they rarely give ranges for them [06:22:35] https://docs.google.com/spreadsheets/d/1iuJ0ruYgXJvbM6b3NhaP7wdop9FBo5l0OB51hDs4LMc/edit?usp=sharing [06:22:54] that's the spreadsheet I've been capturing pinout information in for all of the B tray modules... in varying levels of organization [06:24:26] it's complete enough to build to, at least [06:24:44] ND-1021042, I mean [06:25:52] the biggest pain in my ass so far are the cores used in the ropes and in the erasable switches... but I think I have some now that should work [09:19:53] . [11:51:47] Hey [11:55:05] hey [11:59:45] any progress with the CWEA? [12:00:21] The master alarm is now connected to the CWEA. Still looking if I should keep this implementation or go even more detailed. Right now I have a single bool MasterFF that is the flip-flop of the MA. In the LM it was triple redundant, I could simulate it down to every relay. [12:00:40] http://www.ibiblio.org/apollo/Documents/HSI-208818.pdf [12:00:42] Page 110 [12:01:48] so, my guideline has been, simulate every relay only if a functional difference could arise from that [12:02:25] in the SECS there are a lot of double relays, so two relays which both get energized under certain conditions [12:02:54] but apart from a relay failure, there would never be a functional difference if we are only simulating one relay there [12:03:07] so in those cases I never implemented the 2 relays, just one [12:03:37] If the first MasterFF would fail relay K1 wouldn't get energised. That would still give you a master alarm but no telemetry. [12:03:45] ah [12:03:49] so that is a functional difference then [12:04:09] looks similar for relays K5-7 [12:04:46] it's not a terribly large number of relays in the CWEA, so I think you could do all of them [12:05:20] I'll do that. [12:05:27] you could take one shortcut [12:05:35] just simulate on flip flop, but 3 relays [12:05:38] one* [12:06:07] and then the if-else for the relay driver just sets all 3 relays as true or false [12:07:10] yeah, I think that's the best compromise [12:07:48] I think my initial assumption was wrong. Originally I though that the master alarm would go off if a C/W Power Caution is triggered. [12:09:39] almost looks like the opposite is the case [12:10:02] hmm [12:11:46] if those relays K5-7 are not energized, so the CWEA has no power [12:12:31] then the 3000 Hz tone can't happen [12:12:36] hmm [12:12:58] the wiring is not so easy [12:13:02] Relays K5-7 even pull the MA breaker to ground on a power failure. [12:13:20] Follow the wire right of the tone generator. [12:14:00] they pull it to ground if the relays are not energized [12:14:06] Yes [12:14:40] so what does that mean [12:14:58] tone generator constantly on? [12:15:21] Hmm now that you mention it. [12:15:30] I think so. Tone generator on, MA lights off. [12:15:49] in the case that the master alarm has power, but the CWEA not [12:15:55] And no way to turn it off without pulling the breaker. [12:25:38] so why do the checklists often have you cycle the CWEA breaker? [12:26:43] I think that resets all the signals through the CWEA reset bus. [12:27:21] ah, I see [14:03:02] Good morning [14:04:37] hey Ryan [14:05:53] So I am worried the changes to direct O2 may cause issue down the road until the CM ECS is reworked [14:06:13] The way the actual direct O2 is plumbed and the way the sim treats it are quite different [14:06:55] But I dont think it will have any awful effects, just will set off the o2 flow light every time [14:07:27] which might be correct [14:08:01] Could be in space, but when on the pad there is a checklist item to adjust for 0.6-0.8 LBH [14:08:44] However since the direct o2 flow is added to the other flows, it measures an o2 flow of 4-5 LBH instead of 0.6 or so [14:09:01] hmm, I see [14:09:18] Because the sensor just adds all flows where the actual ecs system has the direct o2 downstream and it is not an additive function from what I can see [14:09:44] But again, nothing detrimental, just a little annoying for now [14:10:45] It can be played with of course but unfortunately changing the flows is not as simple a fix as I thought to remedy the CM haha [14:11:03] But it should be safe to keep for now [14:12:57] So Mike and I came up with a crude heat load for the LGC in standby [14:13:25] 0.5A at 28VDC would use 14W of power and thus 14W of heat? [14:14:32] sure [14:16:26] Now I other then some power data, the CDU and PSA heat are still a little enigmatic [14:16:30] *Now other [14:17:29] The PSA gets power from both IMU breakers and the LGC breaker [14:18:13] I have a breakdown of the PSA supplies but no amperages [14:18:44] Looks like the national water management agency is closing all the flood barriers. [14:18:51] Quite a heavy storm today. [14:18:57] Where at? [14:19:09] Every one in the country. [14:19:23] Otherwise we flood. [14:19:37] Yikes [14:20:09] yeah, we have quite the storm here as well [14:21:03] https://en.wikipedia.org/wiki/Delta_Works [14:21:33] They are even livestreaming the closure of https://nl.wikipedia.org/wiki/Maeslantkering on the news. :P [14:22:24] The engineering of such structures is fascinating [14:22:49] You guys stay safe out there [14:22:57] Its just 17 and sunny here haha [14:23:01] 17F [14:23:20] so, -8C or so [14:23:54] They lowered the criteria for closing them. Not because of safety but because they think it's exciting to test under actual conditions. :p [14:24:06] Usually 3.1m now 2.6m. [14:24:43] Well the nice thing is they can sell it as a safety thing [14:25:11] Right [14:26:00] The last time they had to close the barriers was in 2007. [14:34:22] hey [14:35:14] Morning [14:36:44] So thinking it over, the increased heat from the LGC breaker when compared with the power on the breaker itself is likely heat generated by the PSA, PTA and/or CDU [14:38:34] yeah [14:38:36] hey Alex [14:39:19] Interesting the IMU OPR has a 200W power load but a heat load of only 78.6W [14:40:08] maybe that's where the increase heat in the e.g. GASTA is coming from [14:41:46] Could be [14:42:31] I think we are just going to have to get it close haha [14:49:01] uhh, can you explain this PR? [14:49:06] about the Direct O2 [14:49:12] what did you change? [14:52:16] Looks like a checklist change [14:52:21] Checklists [14:52:29] yeah, but to what [14:52:41] One notch instead of wide open [14:53:26] I see [14:53:32] For the "adjust for 0.6-0.8 lbh" [14:53:36] is that different from the proper launch config though? [14:53:44] Nope [14:53:52] or is there not "the correct" position for the Direct O2 [14:54:05] For that step its adjust to a certain flow [14:55:26] all good then [14:56:00] The actual verbiage is "DIRECT O2 vlv - open (CCW) (>2 in H2O on SUIT/CAB dP ind) (O2 flow - 0.6-0.8 lb/hr) [14:57:04] Also all the checklists had "LPM ingress" not "LMP ingress", minor spelling change [14:58:01] lunar pilot module [14:58:22] that's the module in which the lunar pilot is stored until he is needed for LM activation [14:58:38] Haha I'll go back and change it... :P [14:58:59] I also don't believe in the SECRA [14:59:02] Hahaha [14:59:14] pretty sure it was a typo as well [14:59:15] Yeah I am not a believer either [14:59:23] I couldnt find anything for that when I looked [14:59:48] And considering every other acronym in that diagram is in the glossary... [14:59:54] Brb [15:15:24] So i am wondering if its prudent to start by taking the heat loads in those systems attached to the lgc and imu breakers, using the power consumption for them, and talking the remainder and divvying it up between the other heat sinks [15:18:29] Then figuring out a clean way to have the imu case vent to the radiator when in standby/on the heater, and give excess heat to glycol when operational [15:22:40] I guess the important part is that the combined heat load is about right [15:23:17] Yeah that will give proper results [15:24:28] With everything running the glycol should be about 40-45 degrees at the accumulator [15:25:04] But 80-100 at its hottest point is possible [15:25:40] The boiler in the real LM can handle like 6000W or so [15:27:00] Of course that's including heat from the pumps and the cooling heat exchanger and such not just systems [15:29:39] When fanning the pumps add Q dont they? [15:33:19] our pump class does not add any energy [15:34:26] What about indirectly via pressure increase [15:35:01] well yeah, that of course it does [15:38:44] Ok thats what i meant haha [15:40:11] cya [16:52:33] Crap [16:52:51] I accidentally went to 100x time acceleration instead of 10x. [16:52:54] CMC Restart. [16:55:03] Had to do a V36 to get the DSKY back. [16:55:26] Parity and TC Trap. [16:55:48] aka RIP erasable memory [16:58:14] State vector is a mess [16:59:59] Both state vectors come up with complete garbage in P21. [17:04:10] IMU still agrees with GDC [17:10:53] Welcome back [17:11:45] My CMC is bust. Accidentally went to 100x acceleration and got a restart. [17:12:11] Both state vectors are complete garbage and I'm pretty sure there's more things that are corrupted. [17:12:27] Where can I fetch the telemetry client again? [17:14:15] good question [17:14:44] I thought it was in the old sourceforge CVS [17:14:59] but you can't seem to access that directly anymore [17:15:26] We really need to give it its own repo [17:15:31] yep [17:15:41] Best of all. ibiblio is down again. [17:17:00] Wasn't there some kind of recovery pad load that could be uplinked? [17:17:05] indeed [17:17:11] we have them for a few missions [17:17:23] and we should create them for the other missions that had that [17:17:39] Apollo 8 didn't have the backup erasable load in the checklists yet [17:17:49] we have Apollo 14-16 [17:18:01] oh, not uplinked [17:18:07] it was in the checklist [17:18:11] That's the one [17:18:20] for manual entry into the DSKY [17:21:00] it's still on Github [17:21:10] in older versions [17:22:45] https://github.com/dseagrav/NASSP/tree/1b507b8a9f0bfb9a319ea789aea76a15589595c5 [17:22:57] this was one commit before it got removed [17:25:21] so, I was cleaning up some LEM code and through that I found that we have a fairly complicated sound file handling for the lunar landing [17:25:25] with many files for Apollo 11 [17:25:41] only problem is, it was connected to the old lunar landing autopilot [17:26:49] so I am not quite sure what to do with all of that [17:27:23] it accessed time since PDI, altitude and a few other things [17:27:31] and then played the right sounds accordingly [17:27:59] I think we need a whole new concept for historical audio anyway [17:31:28] morning! [17:32:28] hey [17:33:23] is the ACA checked at all in P63 or P64? [17:34:44] Hey Mike [17:34:54] yes, you can switch to Att Hold [17:35:13] hmm [17:35:32] but I assume its position is only checked after that [17:35:34] that's normal procedure even [17:35:41] to check manual control before you need it [17:36:13] thewonderidiot: Bit 1 in the restart monitor "E Memory or F Memory Parity Fail". Is there any way to know in what memory that occurred? [17:36:36] bit 2 is set if it was for erasable [17:36:49] Hmm [17:37:07] I don't simulate erasable parity alarms, since there isn't a real way for us to get them [17:37:13] I got a fixed parity fail together with a TC TRAP. [17:39:15] And my REDOCTR got reset [17:40:03] would going from 0 to 42 counts and back be a computational burden right now in yaAGC? [17:40:13] depends on how often it's done, I guess [17:40:31] I haven't connected my joystick for my attempts so far [17:40:32] I was just trying to think of counters that would stop in P66 [17:40:49] so I've been using the keyboard, which is always full deflection of the ACA [17:41:13] I mean it doesn't matter right now since yaAGC doesn't count anything [17:42:18] by the way, I found a silly error in every AGC program we have last night [17:42:23] or most of them, at least [17:42:56] every one that has an erasable definition for EMSD, the unused EMS counter, has it defined at the wrong address [17:43:01] even SuperJob has it wrong [17:43:17] pretty good indicator that they *really* never tried to use it lol [17:43:26] wow [17:43:40] is that an output counter? [17:43:43] yep [17:44:08] so it would probably have been used for reentry and rendezvous, very interesting [17:44:27] originally meant to send velocity information to the EMS in the CM, and test data to a "LEM Monitor" (counter name LEMONM) in the LM [17:44:34] but it wasn't used in either spacecraft [17:44:42] LEMONM at least has the correct address defined [17:44:51] thewonderidiot: Can I force yaAGC to not check parity while still using a parity rope? [17:44:58] I don't think so [17:45:43] LEMONM is probably something that detects if a LEM is docked or not? [17:45:45] you can switch off all of the alarms [17:46:04] something like that -- nothing I have about it goes into much detail [17:46:28] pretty sure the flag for it that gets used is also called like that [17:47:08] no, actually not [17:47:13] just "a LM monitor function" is what Symbolic Listing Info says [17:47:16] where have I read LEMON before... [17:47:30] "Cell assigned for LM monitoring purposes" [17:47:48] So simply setting CheckParity to 0 won't work? [17:48:25] ah, that looks like it would work [17:48:32] maybe I've just seen it in the AGC code, it's just under THRUST after all [17:48:41]