[17:07:50] NASSP Logging has been started by thewonderidiot [17:10:37] hey [17:11:56] what's up? [17:12:29] a little bit manual writing for the FDO MFD, that's it [17:12:40] and you? [17:12:41] documentation? who writes that :P [17:13:01] work. started on the core rope simulation panel for the monitor last night [17:13:57] and I'm doing the math on the AGC thermistor correctly now [17:14:21] yeah, Celsius is so difficult for Americans :P [17:14:38] the celsius wasn't the problem, haha [17:15:08] the problem was that I saw that its temperature characteristic was +4300 +- 300 ppm/C from 25C to 105C [17:15:27] and took that to mean that its resistance increased from 4000 at 25C to 8300 at 105C [17:15:41] buuuut that's not how that works [17:15:42] that sounds a lot like my work on CSM and LM signal conditioners, haha [17:15:58] scaling voltages from temperature sensors and many other sensors [17:16:04] yeah [17:16:45] what that actually means is that the resistance increases 17.2 ohms for every degree Celsius [17:17:11] so at 105C it's 5376 ohms, not 8300 ohms [17:17:14] so I was a little bit off :P [17:17:38] ah, right [17:18:08] 4000 * (4300/1e6) [17:18:37] anyways, it works correctly now, so we can see how hot the AGC gets inside while running [17:18:40] that is indeed 17.2 [17:18:58] that is useful to know [17:20:53] heard back from David Woods [17:20:57] "I have been helped by the Smithsonian and I do have scans of the [17:20:58] CMP solo book as well as the Alternate & Contingency Checklist. I will [17:20:58] endeavour to get them online soon." [17:20:59] yesssss [17:23:45] NICE [17:23:46] :D [17:24:06] CMP Solo Book is always full of crazy procedures [17:24:11] all the rescue cases [17:24:28] we have a bad scan of the book from Apollo 12 and a good one from Apollo 15, that's it [17:24:44] and 11 is a bit different anyway [17:25:24] excellent [17:26:45] hmm [17:26:58] on Apollo 12 and later it's called CSM Rescue Book [17:27:16] I'm not sure 11 had that one like that [17:28:02] yeah, so it's probably going to be part of the CMP Solo Book [17:28:12] or the Alternate & Contingency one [17:28:21] but both will be online soon, so it doesn't matter [17:28:54] they changed the format and number of checklists around quite a bit, based on crew feedback [17:29:06] from Apollo 13 to 14 many checklists were renamed and reorganized [17:31:13] on Apollo 11 LOI Aborts are in the CSM Operations Checklist, not the Alternate & Contingency Checklist. Doesn't make much sense to me [17:32:57] Apollo 15 had it in the CSM Contingency Checklist [17:37:30] yeah that does make more sense [17:44:39] Hey thewonderidiot, just realized that the discrete CDU control signals for the IMU from the AGC are not DC, but instead AC signals oscillating at 102.4KHz [17:45:20] For example the torque enable and select discrete signals used in IMU fine align. [17:45:48] oh really? that's interesting [17:45:52] what generates the AC? [17:46:12] wait which signals? [17:47:12] The torque enable signal, the 6 torque select signals used to perform the IMU fine alignment. [17:47:40] Reading this in ND-1021042 [17:48:46] I'm assuming that it made things easier to transformer couple a high frequency signal across to the CDU. It's interpreted as a DC enable level by the CDU as far as I can tell [17:49:31] You enable torquing, select the gyro and direction, then pulse the torque signal at 3200pps. The enable and select oscillate at 102.4K [17:53:08] Hmmmm, the IO schematics don't seem to agree with this. [17:53:43] haha I meant signal names [17:53:50] I can't remember them off the top of my head [17:54:11] I'm at work with limited ability to look up signals, trying [17:54:49] from page 2-10 of ND-1021042: "The torque enable pulses are a train of pulses three microseconds in width and occurring at 102.4 kpps." [17:55:17] oh yes [17:55:25] does the transformer coupling make that effectively AC? [17:56:16] Best I can guess is that if the AGC wanted to send an enable level to a peripheral, that sending a high frequency pulse train for the duration of the desired level would be one way to do it. [17:56:27] GYENAB [17:58:10] yeah GYENAB is fed by a combination of CH14B6 and SB1 [17:58:53] So it's the SB1 creating the high frequency clocking then [17:58:59] yep [17:59:36] and SB1 is created as P05 & P03 from the ring oscillator [18:00:32] Yeah, this makes things interesting using a 64MHz microcontroller. Cannot run interrupts at that speed. Think I can use an averaging filter on an analog input to see if that pulse train as a DC level [18:01:23] Will need to treat all these as an oscillating signal and measure an average voltage from an ADC to detect logic level [18:03:30] hmmmm [18:04:14] you could also put some conditioning on the beginning -- something like the AGC's oscillator alarm circuit [18:04:23] yeah, cannot process an interrupt every 9us or so. All I need to be able to do is detect that the pulse train is present [18:04:30] or heck even a capacitor could potentially work [18:04:48] Yes I could. Trying to solve this without any more HW. It's a challenge.... [18:05:18] hmm [18:06:23] I can configure any input pin as an analog input with a defined integration time. Can easily detect a couple cycles of 102.4K (I think) [18:06:31] okay another idea then -- could make a function to read the enable state, and have it just sit in a loop reading the GPIO for a length of time during which you'd be guaranteed to see it if it was toggling? [18:06:47] or would that take too long? [18:07:40] Yes something like that. Would require about 20us per signal to ensure at least one full cycle was detected. AGC sets these 312us before other signals so plenty of time I think [18:08:37] but if any pin can be an ADC input then that sounds like the easiest approach [18:10:20] Yeah, the PIC architecture is very flexible and generous with it's IO peripherals. All pins can be configured as analog. Going to give it a try. [18:12:42] yeah that is surprisingly flexible haha [18:12:54] I'm not sure I've ever worked with a part like that [18:16:18] Just wanted to share what was unexpected to me. The fact that those discrete levels are actually "AC" pulse trains and not DC levels. [18:17:14] yeah it is strange [18:17:38] I ran into that back when I was doing the yaAGC counter rewrite [18:22:45] all of this is just increasing my desire to make a CDU simulator [18:22:47] :P [18:34:19] The more I look into the CDU, the less I understand. My personal goal is to treat the CDU as a black box and only emulate it's external signal interfaces well enough to fool the AGC software :) [18:35:20] "The more I look into the CDU, the less I understand." Yes, me too. And I haven't looked as hard as you :D [18:37:03] hahaha yeah, I'm in the same boat [18:37:29] that's why I want to make a proper simulator, so I can see it operate like I can with the AGC hardware sim :D [19:46:37] maybe I'll do that after July to take a brief break from nonstop AGC stuff [19:46:57] we should definitely have all of the schematics by then [19:59:39] sounds fun [19:59:41] good night! [16:43:07] morning! [17:40:20] SteveH, finally got core rope simulation fully integrated into the FPGA last night -- the only thing remaining is to putting all of the corresponding ROM loading logic into the GUI [17:40:50] and testing once the simulator board shows up of course :D [17:51:09] Sounds great, can't wait to see this plugged into the real AGC! [17:51:50] man, me too [17:51:50] I spent my evening mapping CDU signals to appropriate microcontroller pins so I can handle all the various types of IO signals involved. [17:52:08] sweet [17:52:14] did you get to test the ADC thing yet? [17:52:34] What flight software is in the physical AGC? Is it one we already have or is it something new? [17:52:55] none, we don't have any ropes, just the rope simulator boxes [17:53:00] which we're also going to try to use [17:53:37] No have not tested the ADC thing yet. Soonest will be this weekend. Pins arriving today to make the cable from AGC to emulator. Then I need to figure out the program sequence to command the IMU into fine align mode when I don't have an optical system yet :) [17:54:30] haha [17:54:36] It's always something [17:55:28] indeed [17:55:35] I'm really hoping the simulator board shows up before this weekend [17:55:46] I very badly want to test this whole thing at full speed [17:56:06] I understand. I would too [17:57:22] they finished fabbing it and QAing it yesterday and it is just sitting around waiting to be packed and shipped [17:58:07] I need to build up the 6ft cable I'm making between the AGC and the emulator. Need about 30-40 wires right now to get the uplink/dnlink, pipa, and IMU wired up. Then I need port12 wired up to get the switch signals to select imu mode (another 15 wires). This will take a while. [17:58:30] oh yeah sounds like it [17:58:35] harnessing is always a bear [17:59:15] Yeah. After the 2500 ft of 30awg wire wrap in the backplane, it's the single biggest hurdle to a physical implementation. [17:59:37] hahaha [17:59:52] man that is a lot of wire [18:00:03] I don't think I've asked, how heavy is the whole thing put together? [18:00:15] So I figure most likely another couple weeks before I'm ready to try some integrated imu functions for imu zero, coarse align, and fine align [18:00:43] awesome, that will be super cool to see [18:00:46] Have not place it on a scale but I would say on the order of 40-50 pounds for the AGC [18:01:27] sounds about right :D [18:01:31] morning indy91! [18:01:40] in a meeting, back in a few [18:01:47] hey [18:02:10] just quickly checking in, I really should stay in bed being sick, haha [18:02:18] oh noooo [18:02:39] but I had to start my computer to download the CMP Solo Book, which David Woods sent me directly, thanks to my impatience [18:02:47] ! [18:02:48] nice! [18:03:22] first flight plan pages when the CSM is solo, I knew that [18:03:46] then those procedures in detail, I also knew that, CSM Rendezvous Procedures has the same [18:04:11] and then [18:04:13] rescue cases [18:04:33] very similar to what Apollo 12 has, just way better scanning quality [18:04:58] awesome [18:05:04] including contingency and manual insertions [18:05:10] and any time liftoff [18:05:28] and at the end, contingency EVA checklists and charts [18:06:09] more overlap with the rendezvous procedures document than I thought, but still some unique things and better quality than elsewhere [18:06:23] cool, so nothing super new or surprising, but still really nice to have [18:07:00] yeah [18:07:25] CSM Rendezvous Procedures did not have contingency, manual or any time ascent [18:07:32] Apollo 12 had that, but in low quality [18:07:56] contingency insertion is LM with low performance [18:08:00] 10x10 orbit targeted [18:08:25] instead of the usual 18x45 [18:08:53] manual insertion is interesting. Some procedures have it burn to depletion [18:09:01] to avoid not making orbit at any cost [18:09:21] but if the apolune becomes too high, you aren't really able to do the rendezvous with the CSM [18:09:46] right [18:09:59] I've tried that, DKI Processor didn't like it much :D [18:10:18] hehehe [18:10:22] what you prefer to do is letting MCC-H call out the time you cut off the engine [18:10:44] based on whatever info they have on the LM trajectory [18:11:28] any-time liftoff gets you some weird trajectories as well [18:11:59] CSM needs to spent a lot of DV in some cases to get to the LM before it runs out of batteries [18:15:50] and this checklist also has the revisionitis illness like lots of checklists on Apollo 11 [18:16:05] haha [18:16:10] what do you mean by that? [18:16:11] up to revision D from July 10th, then handwritten revision E from the 11th [18:16:18] oh boy, handwritten revisions [18:16:19] well, LM Timeline Book was worse [18:16:23] they got up to Revision N [18:16:42] hehehe [18:20:16] so what about the other checklist? are you getting that directly too or are you more patient for that one? [18:21:11] it sounded like he has to organize the scans of that and is them sending it directly as well [18:21:20] awesome [18:21:21] I wonder if we get any padload surprises :D [18:21:30] because that one will have the backup erasable load [18:21:47] hmm, we have the flight load now right? from Don? [18:21:53] yes [18:22:03] what sort of surprises could the backup load have? [18:22:11] not many really [18:22:20] or any [18:22:23] but it's possible [18:22:26] hahaha [18:22:31] the checklist should be flight identical [18:22:35] cool [18:22:38] anything else would surprise me [18:22:43] so in the worst case it's corroboration [18:22:58] they even made the effort, after liftoff, to fix the TEPHEM value to the precise one [18:23:09] that's why I know that that checklist has a backup erasable load [18:23:17] from the transcript [18:23:36] haha gotcha [18:23:44] the number in the checklist will have exactly 13:32:00 UTC [18:23:55] but the actual CMC liftoff time will be a few milliseconds off [18:24:15] and they changed that in the checklist on every mission that flew a backup load [18:24:34] obviously necessary on 14 and 17, haha [18:24:52] why's that? [18:25:00] they launched hours later than planned [18:25:03] not just milliseconds [18:25:11] ahhhh I did not know that [18:25:12] got it [18:25:28] checklist will of course have the planned liftoff time [18:26:20] from an Apollo 15 document I know how much the TEPHEM usually could change [18:26:23] yep [18:26:32] IU GMTRR 13/33/43.06 [18:26:41] AGC GMTGRR 13/34/00.79 [18:26:55] liftoff time planned 13:34:00 [18:27:05] IU GRR is 17 seconds earlier [18:27:10] so up to a second [18:27:20] which is quite a lot [18:27:24] more than we are getting for sure [18:27:26] that is a lot [18:27:34] but even we get 2-3 timesteps I believe [18:29:25] I made liftoff more complicated in the last few years, haha [18:29:34] that signal needs to propagate between different systems [18:29:41] you made just about everything more complicated I think :D [18:29:57] actually, the Saturn Systems Handbook will help me figure out what exactly liftoff means, electrically [18:30:05] I still was missing a few pieces of that puzzle before [18:30:06] oh cool [18:30:15] oh I need to send that one to Ron [18:30:18] I mostly knew what is going on in the IU, but not 100% [18:34:31] the notes from Mike Collins are gold [18:34:51] oh yeah? [18:36:01] 103:30 to 104:00 GET [18:36:08] just one point, Photography [18:36:12] crossed out [18:36:14] instead [18:36:18] EAT! [18:36:31] hahahaha that's awesome [18:36:46] then below that [18:36:51] 4 PM local [18:36:56] No Lunch [18:37:01] (Practically Breakfast) [18:37:21] hehehe [18:37:33] and some occurances of "at convenience" do this and that [18:37:40] at convenience crossed out [18:38:03] most other stuff is of more technical nature [18:38:05] lol [18:38:08] P22 inputs outputs etc. [18:38:16] lots of those [18:38:26] the quest of finding Eagle on the surface [18:38:46] at 107:25 [18:38:54] "Follow Flight Plan until 124:00" [18:39:00] 124:00 circled with the note "Ok" [18:39:55] later flight plans have more space to note down things in the flight plan itself [18:39:59] I think I know why now, haha [18:40:08] because of some particular snarky CMP :P [18:40:48] who wrote things all over the place [18:40:56] including the CM itself as well [18:41:09] https://history.nasa.gov/afj/ap11fj/cm-107_graffiti.html [18:41:39] nice [18:42:44] P34 comment "Slow Comp Cycle!" [18:42:47] Slow underlined twice [18:43:11] they still had the hardcoded precision offset in P34, which makes it take much longer [18:43:30] that was changed on the next mission [18:44:45] where it would try to figure out the necessary trajectory to the other vehicle via the coasting integration routine (twice) and not just the analytic solution [18:44:53] that takes much longer [18:45:41] ok, no second checklist yet. Back to bed. I might be on later if I have to save yet another checklist [18:45:55] haha alright [18:45:57] cya! [18:46:02] feel better! [16:42:47] morning! [16:54:47] Good morning. [16:55:17] what's up? [16:56:57] Nothing new on my end, just saying good morning so you would not feel ignored. :) [16:57:05] hahaha thanks :) [16:58:57] well since you're here, you wanna take a look at what I have for the CRS panel so far? I haven't implemented the logic behind it but I'm closing in on how I want it to work [17:02:04] Sure, fire away! [17:02:34] https://i.imgur.com/rFkrCy9.png [17:03:08] so it's got the same 2 rows of 18 switches that the original monitor had [17:03:21] plus "all" and "none" buttons to set and unset them all for convenience [17:03:52] help me out, is rope zero the erasable memory? [17:03:53] there's also a single switch for banks 44-77 if you happen to want to use the remainder of the superbank address space for something [17:04:02] nope, this is all rope banks [17:04:06] there'll be a separate panel for erasable [17:04:31] gotcha [17:04:52] Assuming the load/dump switches pop up a file selector dialog or something similar? [17:04:56] yep [17:05:21] the bank switches are multi-purpose; in addition to being the enables for rope simulation for each bank, they also control what banks are loaded/dumped via those buttons [17:05:35] so if you only want to load bank 7, you can check that and then load a bank 7 binary [17:05:35] What's the use of crs/agc switches? Wouldn't anything not selected be agc by default? [17:05:54] the CRS/AGC switch is for use with "DUMP" [17:06:17] ok, so you can dump a crs file back to another file? that' [17:06:28] that's a file copy done the hard way :) [17:06:41] haha that's more the problem than the reason [17:06:48] because if you have the CRS enabled, the FPGA will stubbornly simulate your attempts to dump AGC rope memory [17:07:05] setting the switch to AGC will inhibit rope simulation for the duration of the dump [17:07:31] so you don't accidentally end up dumping your loaded rope [17:07:50] okay, makes sense. I think your at least 95% of the way there, I don't see anything jumping out at me. [17:08:22] Assume then there will be a very similar erasable memory panel with far fewer select switches? [17:08:26] I guess I could make it always inhibit and only dump AGC... but I thought dumping the CRS rope through this mechanism would possibly be useful as well [17:08:45] yeah, only 8 switches, but maybe an additional button for padload [17:10:07] in related news, pcbway has shipped the test connector simulator board, so hoooopefully it will be arriving soon :D [17:10:24] Yes. Padload would be very useful. Also maybe a clear button in case memory gets corrupted? I've done this a few times on my AGC already. I've found out that combinations of partial pad loads and missing peripheral signals can make the agc angry [17:10:41] hahaha [17:10:59] to the point that monitoring a register causes the agc to crash... [17:12:01] maybe, although that could also be accomplished by doing a non-broken load, or loading a file initialized with 0's [17:12:09] clearing eraseable memory and reloading padload fixes it when it happens. Most likely a divide by zero, or overflow [17:12:41] Yeah, guess we are saying the same things. I implemented the clear with a padload sequence of zeros via uplink [17:19:42] Given any more thought to the analog meter? It was used to measure duty cycle of various routines. There's a related counter in the telemetry that indicates a count of idle loops every 2 seconds. [17:26:57] yeah, I'll get around to it eventually [17:27:09] it's just not critical path like the rope and erasable simulation are :) [17:29:03] Understood, definitely in the nice to have category. I'm mostly curious how useful is ends up being for measuring execution times and calculating remaining compute time available etc. [17:35:43] it seems like that would be difficult to set up [17:35:58] it's on I, S, or W comparison matches, right? [17:36:04] or CRS cycles? [17:37:12] I guess you could put an S comparison on an executive idle instruction [17:38:23] Don't have any reference material in front of me right now but that sounds familiar. I would need to dig into it again to figure out what they used for a time base to measure the percent comparison matches against. [18:07:16] man, I'm a lot more impatient for this simulator board to show up than I was for the monitor board itself [18:09:17] I can relate. UPS messed up my parts delivery and they are arriving 2 days late. It's killing me.... [18:09:25] oh damn [18:09:34] that suuuucks [16:41:09] morning! [17:54:14] hey [18:00:28] hey! [18:00:33] feeling any better? [18:00:46] a bit [18:01:14] got the other Apollo 11 checklist [18:01:24] in my spam folder [18:01:32] hahaha [18:01:43] good work, spam filter [18:01:51] no padload differences [18:02:23] a few handwritten changed bring it to the state of the padloads document [18:02:33] changes* [18:02:35] oh interesting [18:02:43] well that's good :D [18:02:53] so it was printed a bit earlier [18:03:12] and then the changes done during the flight [18:03:40] the padload document is missing a page [18:04:03] oh right, I forgot about that [18:05:38] other than that, P23 schedule and Earth orbit reentry procedures [18:07:34] nothing too surprising [18:21:39] I'm off again, cya! [18:42:50] At work and can't talk now but found this at a thrift store over lunch [18:42:52] https://cdn.discordapp.com/attachments/389685290807328770/566320508375793694/image0.jpg [18:45:51] Suzuran[werk]: nice! [22:25:16] Sadly, I must report that the Von Braun record is not playable; It was allowed to mold and does not track. It will require cleaning and until then trying to play it will just damage it further. [22:31:37] boooo [17:58:46] hey [18:03:26] morning! [15:57:42] hey [16:00:32] hey Alex [16:00:52] are you ready for Christmas? [16:03:17] nice!! [16:03:42] very cool [16:04:10] David Woods got them for the AFJ [16:04:30] and I got "advanced copies" of the Alternate & Contingency Checklist and the CMP Solo Book [16:04:48] Launch and Operations Checklists are already on the AFJ website [16:04:55] finally a proper G&C checklist for comanche055 [16:04:58] yep [16:05:04] these are scans of the flown copies from the Smithsonian [16:06:34] I got to see the Falcon Heavy launch from a pier about 10 miles south [16:07:35] oh nice, so the launch delays didn't prevent you from seeing it [16:08:16] could you see the landings as well? [16:08:29] I also had a very clear view of the 2 boosters which landed at Cape Canaveral Air Force Station [16:08:31] yep [16:10:31] only 2 months or so until that happens again, haha [16:10:53] which was closer to us then the launchpad itself so we had a great view of the landings [16:11:00] ah, nice [16:11:08] and sonic boom was quite intense [16:11:28] I always thought the landing pads were close to the launch pad [16:12:40] ah [16:12:52] I guess it's closer to LC-40, where the Falcon 9 often launches [16:13:11] https://www.dropbox.com/s/am0s9spitdcrel2/Photo%202019-04-11%2C%206%2037%2003%20PM.jpg?dl=0 [16:13:19] https://www.dropbox.com/s/ql2ldsnfkpdaih2/Video%202019-04-11%2C%206%2042%2041%20PM.mov?dl=0 [16:14:24] looks like a good spot to watch it [16:15:37] yep and weather was perfect, almost no clouds [16:16:03] I was able to follow the Falcon al the way to booster separation [16:17:43] nice [16:47:24] morning! [17:07:13] hey [17:20:58] what's up? [17:23:45] Hey, did your simulator boards show up? [17:24:45] no -- but their estimated delivery is today, so fingers crossed [17:25:26] actually "Arrived at Delivery Facility in SAN JOSE - USA" as of 10 minutes ago [17:26:05] so instead I spent the weekend filling out features -- I added the erasable memory simulation panel and associated FPGA logic and hooked up all of the lights that I hadn't yet gotten working [17:26:21] lots of things ready for testing as soon as the board is populated [17:27:40] My wayward package arrived Friday. I got 3 of my discrete controller boards wired up to the AGC, 38 signals in the current harness. Working on integrating the SPI communications now that I have more than one controller talking at a time. [17:27:49] nice :D [17:28:36] Yeah, added 2 additional connectors and 6+ ft of wire to the signal paths. things still appear to work. :) [17:28:48] haha excellent [17:53:34] woo, board is out for delivery! [17:54:19] I have a feeling tonight is going to be a late night between commuting home, driving to pick up my board from Marc's place, driving back, and soldering it all up [17:54:31] because I have no self control :D [18:01:17] indy91, I have a joystick connected that does not have a throttle slider. I was thinking NASSP would see this and let me use the INS/DEL keys for controlling the LM DPS in manual mode, but it seems it just thinks my joystick does have a throttle slider and the its stuck at 100% [18:02:49] Is there a way to make it so that I can use that joystick and have the keyboard keys work for controlling the DPSÉ [18:15:32] no [18:15:45] maybe there is a way to detect that in code [18:15:51] but right now it's probably not possible [18:16:00] right [18:16:32] indy91: I have another more complicated possibility problem for you [18:16:36] but there probably is a way to disable that system side [18:16:43] maybe in code there could be "if no slider, use keyboard"? [18:16:57] yeah, if that's possible to detect. It might be [18:17:00] sure, Mike [18:17:22] like, TTCA with broken throttle setting, maybe that works by pulling some CB [18:19:21] Marc wants to know if it is possible to do an open-loop landing with the AGC -- pre-record all of the inputs generated to the virtualagc in an NASSP landing, and play them to the real one, and have it be happy enough to do the whole descent without aborting [18:19:38] my stance was that the conditions probably aren't repeatable enough to keep it from panicking but he is not convinced [18:20:29] well, if we are talking about all of the inputs, including PIPA and IMU [18:20:33] well, that's redundant [18:20:34] IMU [18:20:38] haha yeah [18:20:55]