[23:36:22] NASSP Logging has been started by thymo [23:36:43] That's what you get when playing with router settings [23:50:16] haha [23:50:19] yeah, you have to PM him [17:47:15] morning! [17:54:08] hey Mike [17:58:38] what's up? [18:00:08] working on something that equally applies to Shuttle and Apollo [18:00:47] more rendezvous technique stuff? [18:00:56] analytic ephemeris generator [18:01:00] aha, nice [18:01:02] so find state vector at time X in the future taking into account nonspherical gtavity [18:01:13] but, analytically, not numerically [18:01:42] pretty sure the AEG was used by Shuttle FDOs almost unchanged from the Apollo days [18:01:55] we actually have the program flow for it [18:02:04] in one of the IBM RTCC documents [18:02:18] oh sweet [18:02:19] but it's handwritten and not very readable in places [18:02:25] so basically unusable [18:02:28] oh damn [18:02:31] that sucks [18:02:33] one typo could ruin it :D [18:02:50] but I basically know what equations they were implementing [18:03:06] and GMAT has that implemented as well, that's why I was looking at GMAT code yesterday [18:03:31] it already works, but the errors are larger than I'd like, so I am trying to find some bugs [18:03:34] it's* [18:03:40] no, it was right [18:05:18] 70 meters difference to numerical integration over 95 minutes, 1100 meters over 24 hours. That's not bad, but I think it should do just a tiny bit better [18:05:36] with the numerical integration being more accurate? [18:05:38] the equations are gigantic, so probably a small error somewhere [18:06:00] yes, I'd think so [18:06:18] I am actually checking two numerical solutions [18:06:40] one I have in MATLAB and then what I am using in the MFD code, based on the AGC coasting integration routine [18:07:38] just brought those in agreement. I was using a mass for the Earth in MATLAB that was from the AGC [18:07:42] was off by a bit [18:07:59] so now I just need to figure out the bug with this analytic method... [18:12:47] so tell me about the erasable memory module that the museum has [18:13:17] well, all of its internal wiring is intact, lol [18:13:41] it does have a bad bit... I think it is bit 12 or 13 of location E0,1723 [18:13:52] it was removed from computer PC-2 because of that [18:14:04] E0? [18:14:09] erasable bank 0 [18:14:12] is that just address 1723 [18:14:15] yeah [18:14:48] yeah it's bit 13 [18:14:49] so it's not in the memory with several overlays [18:15:08] was removed from PC-2 on March 7, 1968 [18:15:31] oh noooo [18:15:42] that's the permanent state vector for the other vehicle [18:15:48] in Luminary099 at least [18:15:53] haha [18:16:15] so it probably would have trouble with that [18:16:31] that could be why then :) [18:16:50] probably some issue while it was reading that bit [18:17:02] certainly a location that would be written and read to a lot [18:17:05] yeah, the piece of tape says that bit "drops", so it can't hold a 1 [18:17:06] well [18:17:23] every 10 minutes for a whole mission, roughly [18:17:45] I figured they moved it into 200M because they were using test programs, not mission programs, in it [18:18:33] it also isn't completely potted and has a loose wire on its top interconnect because of it [18:18:49] and its cover isn't bonded down for whatever reason [18:20:29] address 1723 is part of the state vector for the "other" vehicle in basically all CMC and LGC versions [18:20:52] which isn't that bad I guess [18:21:03] if it was "this" vehicle it would be worse [18:21:11] it might be "this" vehicle in some versions [18:21:28] just don't try rendezvous with it :D [18:21:45] or else you get a 50/50 chance of the state vector becoming bad, I guess [18:21:49] hehehe [18:22:12] it's the other vehicle in all versions [18:22:30] so not that big of a problem if you were to use it [18:23:26] were they originally using it for running mission software and then moved it to testing? [18:24:52] in Sunburst120 it's a temporary address for the Lambert subroutine [18:24:55] so even less of a problem [18:25:01] don't think it's used for anything else [18:29:49] their computer has Retread 50 in it [18:29:59] and Retread 44 doesn't use that location at all, so 50 probably doesn't either [18:31:49] hopefully we will find out once we get this AGC working :D [18:32:09] I'm working on a button for the monitor right now -- "Dump Fixed" [18:32:31] when you click it, it reads all of fixed memory from the AGC and writes it out to a ROM file [18:32:38] that we can then run in VirtualAGC and disassemble [18:37:55] that's a good one :D [18:46:03] the FPGA side totally works -- I was dumping banks of Luminary 210 last night consistently [18:46:24] just need to figure out how to do this correctly in the GUI :D [19:58:24] There was a chance of getting Comanche067 that way, right? [18:49:41] I'm not dead :P. I'm sorry I haven't been around things in life get insane! [19:11:20] he lives! [19:12:07] Haha yes how have you been?? [19:13:11] pretty well [19:13:31] life must have been really insane, haha [19:14:10] Yeah I've been working 2 contracts my free time up until just recently has been all taken up [19:15:03] Things are calming down I've missed you guys and the project and doing bads in C++ [19:15:22] you don't have to do as much bads in C++ [19:15:35] Haha if you insist [19:15:36] there is someone who wants to make a uni project out of the ECS [19:15:46] Oh really [19:16:21] Someone new or Thymo [19:16:27] new [19:16:36] we still want to release NASSP 8 for the Apollo 11 anniversary. So we are only going to be doing a few tweaks to make the LM ECS more stable and leave it at that [19:16:40] Interesting [19:16:46] and that big update, if it is coming, will be in the next version [19:17:11] so all left for you is checklists [19:17:16] Well as things calm more, I'll have to dive in and play [19:17:27] Yeah I know where I left off on 11 [19:17:36] I was searching for some more flight controller documentation [19:17:40] I just have to get my head back into gear [19:17:41] which I found, but for Shuttle, not Apollo [19:17:48] Ah of course [19:18:00] so right now I am very distracted with developing a MFD for Shuttle rendezvous planning [19:18:15] For orbiters shuttle? [19:18:21] yeah, SSU mostly [19:18:46] Very nice [19:19:16] what is found are FDO Console Handbooks [19:19:25] step by step instructions on how to do certain things [19:19:32] how I wished we had something like that for Apollo [19:19:37] Yeah seriously [19:19:47] Would have saved a lot if guesswork [19:19:53] but it likely doesn't exist in the same form. But there were console handbooks, personal notes I guess [19:20:12] Need to find some living FIDO's [19:20:42] I have found some Shuttle FDOs on Twitter if I ever need to ask something :D [19:21:10] They might have connections to older ones as well [19:22:04] speaking of connections to older ones, the handbook also mentions a lot the background of some of their calculation tools [19:22:13] and it's a direct descendant of Apollo, very clearly [19:22:29] not much developed in some cases [19:22:35] Oh I'd imagine orbital mechanics of LEO hasn't changed much ;) [19:22:36] just a nicer user interface [19:24:07] Oh random, kind of off the radar, but Grumman has put in a bid to the us government on a new manned lunar lander project, not sure any details but my girlfriend does those contracts numbers and happened to see it [19:24:10] so some of the stuff I am working on might find its way back into the RTCC MFD [19:24:37] yeah, I think they are asking companies for their ideas [19:25:01] How ironic would that be if we got another Grumman lander [19:26:32] well, Apollo and Shuttle were also built by the same company [19:26:42] CSM* [19:27:04] True, but that was almost linear [19:27:11] There wasn't as much of a gap [19:27:20] yeah [19:27:52] I still think a private group is going to beat NASA to the moon :P [19:28:12] yeah, they haven't been exactly quick in progress in the last decade [19:28:23] switching back and forth between Moon and Mars as their goal [19:28:39] Don't forget asteriods ;) [19:28:47] ah right, there was that in between [19:28:56] practicing for Mars [19:29:00] Yeah which just seems crazy [19:29:13] at least we will some flight hardware for the SLS soon [19:29:22] True! [19:31:02] morning! [19:31:04] ryan! [19:31:06] you're back! [19:31:16] Mike! [19:31:18] Yes I am [19:31:37] :D [19:31:39] Actually I have a question for you [19:32:19] what's up? [19:32:23] I'm designing a guitar pedal based off a 60s schematic, I just dont know how to go about making a pcb for it [19:32:47] I use KiCAD for PCBs and like it [19:33:05] And do you get them printed? Or etch? [19:33:12] I have them printed [19:33:21] What's the cost usually [19:33:51] Small board in this case [19:34:01] depends on where you go -- in the past I have used fusionpcb and it can be on the order of like $20-$50 [19:34:08] Ok [19:34:42] The "new" version of this pedal is 160 so I'm trying to save money and customize at the same time [19:34:52] The components are about 25 for everything [19:35:02] yeah you can definitely beat 160 [19:35:04] So I'd still be saving haha [19:35:08] yep [19:35:22] I might run my plans by you, I bought a breadboard to play with [19:35:39] sure :D [19:35:57] I'm going to be working on a PCB this weekend, heh [19:36:01] I understand electronics but I've never done this before [19:36:10] Oh nice [19:36:24] it's a lot of fun, and a lot easier than I thought it would be [19:36:50] Yeah I'm used to simply wiring components together [19:37:12] These pretty much need a PCB to be compact enough [19:37:24] yeah for sure [19:37:30] how tiny are you going? surface mount? :D [19:37:40] Stomp box [19:38:09] So maybe 2x4 for the board [19:38:54] Haven't made the box for it yet though [19:39:04] Just found the parts [19:39:33] And the germanium transistors [19:39:41] fancy [19:40:33] Yeah I learned all about semiconductor chemistry in school it's coming back, basically the less precise nature of that semiconductor leads to a more organic distortion [19:41:09] I see, interesting [19:41:41] I'm basically emulating a fuzz box that Jimi Hendrix modded [19:42:03] They are the simplest pedals to make so I'm starting there [19:42:24] awesome [19:42:27] sounds like a lot of fun :D [19:42:33] Should be! [19:42:59] I kinda got into this after just rewiring my guitar last weekend lol [19:43:13] I've had new pickup for months with no time to install [19:43:54] So I designed a new wiring scheme to get the most out of them series parallel could splits combination [19:44:06] And that made me want to try this [19:44:34] And (not surprisingly) there is a whole subreddit on diy pedals [19:44:52] hehehe [19:44:57] sounds about right :P [19:46:38] I think I have Eagle with my Autodesk software [19:46:48] Ever used that? [19:47:02] I think I might have once.... [19:47:07] a long time ago [19:47:23] I'll download kicad when I get home to start [19:47:52] I think they each have features the other doesn't, and are both janky in their own ways [19:47:58] it comes down to personal preference :D [19:48:05] Along with updating NASSP and VS2017 :P [19:48:14] \o/ [19:48:16] Ok I'll play around with it [19:48:32] It's a simple circuit [19:49:09] I just added a true bypass and a switched input jack to the design [19:49:18] Oh and a LED [19:49:31] yes, can't forget the LEDs [19:49:35] the most important part of any board [19:50:21] What's the best way to attach a pot to a breadboard [19:50:39] Alligator clips? [19:51:16] that would work [19:51:41] I have some learning to do [19:51:52] I don't know that there is necessarily a best way, haha [19:52:44] I might be tempted to solder leads onto it [20:00:02] Ah good idea [20:00:30] Gotta run i won't be a stranger :) [20:02:33] I just found something... [20:13:24] indy91: what'd you find? [20:13:47] Flight Design System documents on the archived NTRS [20:14:03] that's the software used in early Shuttle days for all things flight planning [20:14:07] oh nice! [20:14:14] in some cases it has full program flows [20:14:26] so it's similar to the IBM RTCC documents [20:14:41] it does not have the full program flows for the things I am working on right now [20:14:50] but really good other stuff [20:15:04] 250 pages about Shuttle deorbit targeting. That kind of thing [20:16:13] that sounds fantastic :D [20:16:40] yeah, it's in three books [20:16:48] about 1600 pages all together [20:17:55] it has about 30 pages about the OMP, Orbital Maneuver Processor, which was how my new MFD was named at first [20:18:06] it has some info on how it does iterations, so that is good [20:18:32] "Processor Routines: The only available routine documentation is contained on the comment cards in the software listing" [20:20:12] d'oh [20:20:16] also, hey SteveH [20:20:35] I saw your email but haven't replied to it yet. congrats on getting downlink working! :D [20:21:28] Thanks. No I just need to fix several bugs in the PIC, and write the code to parse the data, and print it, etc... :) [20:21:43] hehehe [20:23:53] SteveH, do you know the display format of it? [20:24:33] the AC Electronics manuals have it for CMC and LGC displays for the CRT screens in mission control [20:26:05] I wonder how they displayed Aurora data [20:27:08] in mission control? :D [20:27:38] haha I doubt it :P [20:27:56] I figure they must have had some console or something to display it... somehow [20:28:12] but it probably would have been quite different from what the AC books show [20:28:26] yeah [20:36:00] man, I think I have to completely rewrite the backend of my monitor GUI app [20:36:03] and it makes me sad [20:40:38] oh no. Why is that? [20:54:24] the restricted NTRS list only goes to 1980. So there are probably a lot of documents archived from 1981 and later, but we don't have a list [21:14:33] I want to do the rope dumping thing in a separate thread that updates a progress bar and things [21:14:45] but for Qt widgets to interact with a thread like that, it needs to be a QThread [21:15:03] and... I didn't know that that was really a thing, so my USB interface thread is a python thread [21:15:09] and apparently mixing the two is a disaster [21:15:17] I was getting crashes left and right [21:15:24] and neither can use the other's synchronization primitives [21:15:25] so [21:15:32] yeah [21:15:59] the 1980 cutoff has been a feature more than a bug up until now :D [21:16:57] mostly, yes, I have always been collecting interesting Shuttle documents as well, haha [21:18:07] hehe fair enough [21:18:34] I got 1600 pages and all I want is more [21:18:51] finding good documents is like drugs [21:18:56] it really is [21:30:12] good night! [18:07:46] morning! [18:36:34] hey Mike [18:36:40] what's up? [18:38:42] working on that analytic ephemeris generator I was talking about in the last few days. Remember how I said it should be more accurate than it currently is? [18:39:12] yep [18:39:41] I read the graph in an MSC paper wrong. It was showing how it behaves when drag is included in the calculations [18:39:51] and it wasn't showing absolute position and velocity error [18:40:03] but position/velocity magnitude [18:40:11] those of course change with time when drag is included [18:40:35] so it was only comparing how fast the orbit decays with analytic calculation vs. numerical [18:40:38] aha [18:40:55] absolute error, even without drag, is probably bigger, I guess [18:41:46] one orbit I was looking at, propagated for 2 days, showed an error of: 1900m downrange, 50m in radius, 4m crossrange [18:42:04] but I guess that is expected [18:42:38] the few other accuracy comparisons I was able to found showed an error of that size or even larger [18:42:41] so I guess it's not so bad [18:43:48] the Shuttle FDO procedures even have some techniques to bias the drag of the Shuttle to get this analytic method in agreement with numerical methods in downrange direction :D [18:44:33] so what's the advantage of the analytical method if the numerical method is more accurate? [18:44:45] one thing is speed [18:45:06] but that's not the main reason I want to implement it [18:45:13] the analytic method directly deal with orbital elements [18:46:03] and you can very easily calculate some interesting points in an orbit with those [18:46:20] that's directly built into the AEG calculations, so much I was able to see in the RTCC documents [18:46:30] for example, find the apogee in 5 revolutions [18:46:31] I see [18:46:38] that makes sense :D [18:47:02] all my methods for doing that previously were rather bad [18:47:13] not very stable and inefficient [18:48:07] other than the difference to numerical methods it's working quite well so far [18:48:07] and why is the numerical method more accurate? does the analytic method not take into account all of the perturbations? [18:48:45] yeah, I am wondering that as well. The calculation terms of this analytic method are already gigantic [18:48:55] but maybe they don't take the whole behavior into account [18:49:25] need to find more papers :D [18:49:29] hehehe [18:49:34] addict :P [18:52:20] of course I still have the handwritten program flow of the AEG in the RTCC documents. Now that I have implemented something very similar I understand it much more [18:59:51] the other theory is that GMAT has an error in its conversion between osculating and mean orbit elements :D [19:00:12] I checked, my calculations are 100% in agreement with GMAT [19:05:22] hahaha [19:05:29] it'd be pretty great if you found an error in GMAT doing this :D [19:10:23] the terms are so lengthy, most papers I have found that should the same equations have at least 1 or 2 errors [19:12:00] they didn't bother putting it in the GMAT math spec though [19:12:56] hehehe [19:13:27] so if you get enough papers you can average all of the errors out of them :P [19:14:11] yeah, I'll just implement all of them, and use the average, haha [19:21:32] so my backend rewrite for the monitor client went much smoother than expected last night [19:22:11] and after doing it, I managed to do a complete dump of fixed memory through my AGC's "test connector" [19:22:29] and the resulting file perfectly matched the Luminary 210 binary produced by yaYUL :D [19:23:46] it took a bit, because the code I used to do it was very dumb... but i should be able to streamline it to be much faster tonight [19:23:47] yay, we have Luminary210 now \o/ [19:23:51] lol [19:24:16] now hopefully we can do this to get Comanche 67, and Aurora 88, and Retread 50, and others [19:24:18] how fast is the process for a completel rope? [19:24:53] I dunno, 30 seconds doing it the slow way? I'll time it once I don't have a bunch of extraneous sleeps in the code [19:24:59] pretty fast [19:25:12] getting Comanche 67 would be nice [19:25:22] does this process require a working erasable memory module? [19:25:53] not at all [19:26:03] great [19:26:53] the AGC's peripheral instructions are pretty cool :D [19:28:15] I suspect that it'll be only a few seconds once I streamline it [19:36:21] not like it matters much. If it takes a day per rope it would still be worth it [19:37:56] Great news Mike! Can't wait to be able to plug your monitor into my AGC some day. [20:19:57] well, it might matter for the owners of the ropes [20:20:11] it's easier to ask for 5 seconds of power than a whole day :) [20:46:23] yeah [20:47:04] do we know of any more ropes? Surely having a running AGC is a convincing argument for giving it you for 5 seconds [20:49:01] those are the ones I know of right now... but I also haven't been seeking them out [20:49:20] once we actually demonstrate it I'll go all in on a search through museums and things :) [20:49:40] Don has two modules, one from Sundance 302 and one from Sundance 306, I think [20:49:44] sadly not a full set [20:56:54] yeah, not being a full set is not helping much [20:57:16] still, I will gladly dump them if Don gives me the opportunity, just in case we locate another partial set with those modules missing [20:57:41] right [20:57:46] they have to be somewhere [20:58:07] why was Sundance 302 even assembled? [20:58:10] 306 was flown? [20:58:19] manufactured* [20:58:24] same reason Luminary 97 was assembled, I assume :P [20:58:30] manufactured, yeah [20:58:44] I think it was probably expected to be the final version, but they found changes to make [20:58:52] let me look at timeline... [20:59:05] that never happens. Except for every other mission, haha [20:59:09] lol [20:59:29] I think Apollo 12 is the only mission where it didn't happen for either vehicle [20:59:40] they nailed it with Comanche 67 and Luminary 116 :P [21:00:07] let's see, so Sundance 292 was April 1968, Sundance 302 was July 1968, and Sundance 306 was October 1968 [21:00:27] 292 was just in time for the LTA-8 chamber testing so I'm guessing that's part of the rationale there [21:01:03] also the Sudnance changes were much larger than we're used to for Luminary [21:01:21] in both cases (292 -> 302 and 302 ->306) they had to remanufacture all 6 modules [21:01:44] so it's not just, one module differs by a word or two [21:03:28] Luminary 116 is a good version [21:03:39] all those annoying radar related bugs fixed [21:27:12] night! [23:45:23] SteveH: FYI, I'm going to try to get the schematic done for the monitor interface board this weekend, and start board layout [23:45:31] if that's what's stopping you from trying it with your AGC [00:51:33] That's part of it. I'll also need to purchase the FPGA board you are using and learn how to load your code on it etc. Not a super high priority for me but it will be fun to have the monitor working. [00:52:44] I think I have the PIC correctly capturing a full downlink list, syncing up with the start of the list, and presenting the list's data via SPI. [00:53:47] Can manually read the captured downlink list one 15 bit value at a time via SPI. Now working on the QT code again to grab the whole list and dump it to console output [17:26:46] morning! [17:33:47] hey Mike [17:35:34] morning! [17:36:17] and Steve [17:36:22] how's it going? [17:36:59] just released another version of my new MFD [17:37:29] Learning how to pretty print data using QString in Qt and Qml...... [17:38:09] it's not using that analytical trajectory method. Instead I used some algorithms from it to find specific points in an orbit and use it with the numerical method. Still quite fast and decent enough in accuracy of finding those interesting points. [17:38:33] nice, to both :D [17:38:35] now I'll test fly STS-114 with it [17:39:58] I think indy91 is having more fun than me though :) [17:40:16] hehehe [17:41:38] haha [17:42:05] but only after having not so much fun figuring some tricky trajectory stuff out. So you are just one step behind in doing the fun things [17:57:38] SteveH, how much do you know about voltage regulators? I'm trying to pick one out for use with the monitor board [18:27:14] Just managed to read one complete downlink list from my physical AGC into a PIC controller that then provides the data via SPI to a Raspberry Pi that displays the data onto a Qt gui. [18:27:46] Only raw octal for the time being, next step is to parse it and display something human readable [18:28:13] How much current is needed for the monitor board? [18:29:08] If you only need a few hundred milliamps then you could use a 3 terminal linear regulator that rated for 2-3 amps without a heatsink safely. If you can do it, that would be the simplest [18:29:42] Otherwise I would go to one of the switching regulators, just need to add a few more passive components with those [18:31:55] oh man, nice! :D [18:32:30] which program are you running? [18:34:57] my baseline is 200mA, but that's using a lot less current to drive the interface than the CTS used (under the rationale that this circuit board will be plugged straight into the test connector and not going through a 30-foot cable) [18:35:24] I am figuring/hoping I can get away with using the same pullup resistance that the micrologic chips use internally [18:35:35] or maybe just a tiny bit stronger [18:36:13] I don't want to overdo it too much, because I don't know how much margin there is on the 14V supply [18:38:00] Just running P00 right now, the coast / align list (77777). Going to start working on the individual parsers for the various types of data fields and put together something of a similar layout as yaTelemetry [18:38:35] I meant, Luminary 210 or... [18:38:58] oops, Luminary 210. [18:39:13] heading out for a while this afternoon. Back in a few hours [18:39:19] cya [18:39:25] later! [18:49:26] oh, I streamlined the rope dumping logic last night [18:49:47] it could still probably go a bit faster with logic tweaks, but right now it takes 12 seconds to dump the full rope [18:52:04] I'm also being a bit too generous about when I release MSTP to let the peripheral instructions run, because some rope instructions try to run too and end up getting themselves massively confused about the whole thing [18:58:52] 12 seconds sounds reasonable, haha [20:54:05] All this talk about dumping the contents of the ropes got me thinking that I have forgotten about the downlink command that dumps the contents of erasable memory. I'll need to add that to my list. [20:56:05] Verb 74 [20:56:34] was done on every mission many times [20:57:21] Yeah, I need to look at the details of the downlink sequence for V74. I suspect I've not allocated enough transfer buffer capacity for those longer data streams [20:58:31] yeah, that's a lot of data [20:58:43] Will most likely get basic uplink working first, then look at V74. I want to be able to use the uplink for installing pad loads so I can start playing with other programs. [20:59:21] pad loads or even any in-mission erasable state [21:00:15] this is not a fun kind of checklist: https://history.nasa.gov/afj/ap15fj/csmgc/9-04.gif [21:00:30] Yes. Then I can implement a confirmation protocol where I can read back via V74 whatever I loaded via uplink. This has been the plan. Then I will start emulating the HW signals for all other peripherals. [21:00:31] manual, backup padload, if you need it during a mission [21:01:22] uplink is a bit more comfortable [21:03:23] Yes uplink is just a series of 16 bit serial writes. I suspect it will be relatively easy once I have downlink going. Will have a gui to manually enter DSKY sequences as well as a file input to upload a file of sequences. [21:05:59] uplinking a text file is certainly useful, our telemetry client can't do that [21:06:23] it can display downlink streams and uplink DSKY commands, that's about it [21:07:09] and of course some non-AGC stuff. [21:20:13] night! [23:05:09] hmm, how is V74 different from regular downlists? are there more words between between syncs? [01:16:37] I need to go back and look. Not sure how many words are included in each message for V74. I think it may be more than the 100 40-bit words of a regular downlink list [18:35:08] morning! [18:47:59] morning Mike [18:48:07] what's up? [18:50:32] Working on some more downlink data formatting and laying out the uplink gui. Picture a DSKY keypad that assembles an uplink sequence with basic backspace / delete editing. A transmit button. and a file selector to select a file to send instead of manual sequence [18:51:37] sounds great :D [18:53:15] I finished the first draft of monitor board schematics: https://drive.google.com/open?id=1N_q52g5tN3Wnt9cWD5ZLzjOVOLj9T5kb [18:53:27] if you want to review, any feedback would be greatly appreciated :D [18:54:50] spent the morning going back through HSI-208616 and also the discussion on scaling and precision within the symbolic listing info. Still cannot figure out the double precision value stuff in the downlink. Waiting to see if indy shows up today. [18:57:48] yeah that stuff is super tricky [20:36:29] hmm [20:37:06] better [20:37:11] SteveH, need some help? [21:21:17] hey Niklas [21:22:57] hey [21:23:03] what's up? [21:25:24] saw that Steve had a question, so I quickly installed Hexchat on this device, haha [21:25:32] hahaha [21:26:27] and I started flying STS-88. This time I installed everything you can for that in Orbiter [21:26:51] previously I just tested the rendezvous stuff with the stock ISS and an empty payload bay [21:29:09] if I make my way backwards through the Shuttle missions I eventually end up with a Skylab rescue or so. [21:29:22] I fonder if anybody every tried SSU and NASSP in the same install... [21:30:21] taking CSM-119 for a spin [21:30:51] hahahaha [21:31:32] I'm sure somebody has, but I imagine it would be a ton of work to learn how to properly fly both :D [21:33:31] SSU is lacking some subsystems completely, so I don't have to know the EPS or ECS [21:34:06] ah nice [21:34:09] prethrust checklist is rather short for the Shuttle, Apollo has like 10x more steps [21:34:51] mostly the SCS is to blame for that [21:35:45] who needs it! [21:37:15] right? [21:38:33] I might to make some SSU pull requests, or whatever that is called with SVN [21:38:53] my MFD already does some calculations closer to the real Shuttle computer software than the SSU code [21:41:56] too bad the Shuttle software also control the ascent [21:42:12] probably the only reason that it hasn't been made public [21:44:03] on the other hand, even this document survived the NTRS purge: https://ntrs.nasa.gov/search.jsp?R=19740004402 [21:44:48] it's also possible that it's out there and there just isn't a Ron or me equivalent trying to shake it out of developers [21:44:59] I dunno how hard people have tried to find it [21:45:14] right [21:45:41] we have learned to be persistent. Which might be my I've already found Shuttle documents that the SSU guys haven't even found [21:49:07] so there probably haven't been a lot of cold emails to developers begging for listings, then [21:49:19] yeah [22:08:32] well, he missed his chance for today. I have to go. Good night! [16:20:08] hey SteveH [16:21:19] Hey, yeah I am going through the downlink definitions and had some questions I was hoping you would have the answers to. [16:22:11] I've figured out the basic scaling of angles and some of the other single precision values but I'm trying to locate some documentation on the scaling and units of the double precision values in the downlink data [16:23:36] GSOP section 2 maybe? [16:24:52] which AGC version are you using? [16:26:36] Currently running Luminary 210. I'll take a look at the GSOP for LM apollo 15-17. Have not look at that yet [16:26:59] https://www.ibiblio.org/apollo/Documents/j2-80-R-567-SEC2-REV12_text.pdf [16:27:32] starting on PDF page 43 [16:27:59] and all the way to the end of the document [16:29:22] I run into double precision values in the downlist specifications for vector components and some delta values. Trying to figure out what units they are in and how to decode them to display. [16:30:16] I assume the downlink data is still in the computational (metric) units, and not in the empirical units used for DSKY display, correct? [16:31:00] yes, that's all in that document [16:31:18] PDF page 52 and later have the actual descriptions of the downlink words [16:31:21] with scaling it seems [16:33:26] Thank you! I was looking at HSI-208616 which has the downlists but none of the details that the GSOP has. I think the GSOP will answer many of my questions, I appreciate the info! [16:34:33] I was reverse engineering the downlist words from the luminary source code, the GSOP will be more efficient I think. :) [16:34:53] haha, yes it will [16:35:02] Now for a little light reading..... [16:38:58] it's a "handful" of numbers that are downlinked, yes :D [17:46:46] morning! [17:55:07] hey Mike [17:56:15] what's up? [17:56:57] flying some more STS-88 and showing Steve how great the GSOP is [17:57:24] hehehe [17:57:39] I think this means that he has officially made the transition from my world to your world, right? :P [17:58:20] well, his downlinks will still be rather empty [17:58:42] details! [17:58:44] once his AGC is filled with a bit more data, then it's my world [18:00:17] fair enough [18:00:19] hopefully soon :D [18:01:11] so I kind of got a feeling for this doing that flat DSKY front drawing... but man the AGC drawings are very... interconnected? within each drawing [18:01:16] not between drawings, but between features [18:01:40] I started last night trying to just draw the area around the test connector so I can draw up an adapter plate for the monitor [18:01:54] but the features of the test connector are referenced not to the stuff around them, but to features on the exact opposite side of the AGC [18:02:40] https://cad.onshape.com/documents/92cad92555e98e88fa5f5e38/w/0e5bae8ff640d26b83a1661a/e/9df4f4569a6ac7ab31eba53a [18:03:00] so I'm making the whole darn tray, so I can figure out what the geometry around the test connector is, heh [18:04:43] haha [18:05:36] it makes sense if you want drawings to build the whole thing :D [18:06:10] yeah. I figure I was going to want to do the whole thing eventually anyways as well, so even once I have enough details filled in for the test connector I'll probably just finish it off [18:07:28] also happily discovered that we have even more details for AGC parts than I thought. NARA doesn't have drawings for parts with numbers like "MS16555-640" -- but these are more publicly standard parts and you can just buy them [18:07:29] https://www.grainger.com/product/GRAINGER-APPROVED-Hardened-Ground-Stainless-5EEK1 [18:07:59] I guess the MS is Mil Spec :) [18:10:31] so the AGC is basically off-the-shelf [18:10:40] almost [18:10:45] practically yes [18:11:07] they really gave themselves too much credit [18:11:28] didn't even have to invent a new alloy or so [18:18:28] and I found a flight plan for my favourite of all Shuttle missions, STS-39. Now I just need to get some of the Orbiter addon devs to create a payload pack I can use. [18:22:29] hmm, I don't know STS-39. why is it your favorite? [18:23:35] indy91, thewonderidiot - I like to think I have a foot planted firmly in both worlds! :D [18:23:50] Although I do admit I need to get more data displayed. [18:24:17] most complex deploy and retrieval mission the Shuttle ever did. A lot of rendezvous operations, 15 OMS burns, 41 RCS translation burns. [18:26:12] oh nice, that does sound like something that would appeal to you, haha [18:26:13] SteveH, I'll guide you to a padload whenever you want, that would be a start [18:26:20] Got a basic question to test my understanding of an example within GSOP (which *IS* awesome btw) [18:26:48] and SteveH, yeah, that sounds right, haha. but you're leaning more and more into Niklas's world all the time :P [18:27:07] all sections of it are awesome, but part 5 with the guidance equations is clearly my favourite [18:27:36] If I see something like (meters/centisecond) 2^5. Does that mean that I take the word value and divide it by 2^5 and that provides the value in meters/centisecond with a fractional component? [18:29:36] should have been (meters/centisecond) / 2^5 [18:29:43] I think usually that means if you take the engineering value and do those operations with it you get a fraction [18:30:15] the fraction being word*2^-14 [18:30:28] I think [18:30:37] do TIME1/TIME2 or the scaler channels come down in the downlist? that might be a good study case, if the GSOP says how to turn them into seconds [18:33:47] of course double precision makes scaling a bit more complicated [18:35:40] time is scaled centiseconds / 2^28. Still working out what that means. Looks like I'll need to work through a few examples. There are a handfull of values with scaling of 2^5 or 2^10 that I'm now trying to sort out for display purposes. [18:36:38] I've converted time times correctly and have them running, but my thought process was not in line with that equation. Trying to think like a 1960s software engineer and it's giving me a headache [18:36:39] yeah, just saying time because you can zero it out and have a known correct answer to compare your conversions against :D [18:36:46] hehehe [18:37:03] I definitely know that feeling [18:38:18] yeah, it can be annoying to deal with [18:38:38] the scaling definitely references the double precision [18:38:43] I think I interpret this stuff as telling me there are some single and double precision values where the lower 5-10 bits are the fractional component. Will try that out and see if it makes sense based one documented limits of values [18:39:05] there are a few examples where my RTCC MFD deals with it [18:39:30] TEPHEM for example, that's the triple precision time of liftoff [18:40:09] and you basically calculate the engineering value (centiseconds) by: EMEM1706 *2^28 + EMEM1707 *2^13 + EMEM1710 [18:40:10] scaling is always super tricky. it took Niklas and I a few tries to get the Zerlina padload scalings right... and I am pretty sure that every single one we had to guess on, we got wrong on the first try [18:40:30] 2^14, not 13 [18:40:54] and then divided by 100 to get seconds [18:41:33] Either way, I have a lot more info than I did 24 hours ago. Now I feel truly dangerous :) Here is the first downlink screen in its infancy a day ago: https://drive.google.com/open?id=1j6xF4nmLoW9jYNEwCXfpnCQRff1QrgFp [18:42:38] very nice [18:42:46] or a (meters/centiseconds)/(2^7) example [18:42:58] 37777 as the octal [18:44:00] in decimal 16383 [18:44:50] 16383*2^-14 for the fraction [18:44:58] well, that basically gives "1" [18:45:18] so 1*100*2^7 [18:45:26] gives 12799.21875 m/s [18:46:06] and double precision just will give more decimal places [18:47:06] where did you get the 100 from? in 1*100*2^7 [18:47:19] 100 centiseconds per second [18:48:18] ah okay. I got 16383 / 128 = 127.99218 m / centisecond [18:48:28] yeah [18:48:48] so it is value divided by the scaling factor (2^7) in this example. [18:49:28] 2^7 might be a bad example, because it kind of works both ways with the fraction to word being 2^14, haha [18:50:47] but the same logc for 2^5 gives 3199.8 m/s [18:50:52] which makes a lot of sense [18:51:21] that's the maximum a moon-centered velocity could be [18:52:22] a really high speed TEI or flyby gives you about 2800 m/s [18:53:01] so yeah, I think that's the general process with scaling [18:54:31] use the value that the downlink gives you and divide by (2^14). Then apply the scaling backwards [18:55:02] with double precision, god knows [18:55:37] Apollo 14 had some fun quirk where they got a triple precision number that consisted of positive and negative numbers after a clock update [18:55:44] now THAT is something I don't want to deal with [18:55:48] hahahaha [18:56:24] that's what you get when you let the AGC do the math itself for that [18:56:31] instead of loading a specifc value by hand [18:57:54] https://history.nasa.gov/afj/ap14fj/08_day03_get_update.html [18:58:01] search for 055:46:43 [18:59:43] goes into some detail with the AGC behavior [19:00:36] lol, love it. an entire paragraph of explanation and the read-back is "In other words, you want us to leave the loads the same" [19:01:09] hehehehe [19:01:20] classic astronaut response [19:02:01] something like that is the main reason why we run modified AGC versions for Apollo 10 and 14 [19:02:39] you know it's complicated when mission control ends an explanation with "Does that make sense to you all?" I don't feel so bad now about being confused. [19:02:45] otherwise the reference for TEPHEM between CMC and LGC on those missions would be a year apart and you would have a negative number in one AGC and the same time being represented by a positive number in the other AGC [19:02:55] yeah, haha [19:03:12] what preceeded that call was one of the flight controllers explaining it to the CAPCOM I guess [19:03:28] and that flight controller will hopefully know a bit more about it [19:04:44] or that flight controller asked someone in one of the back rooms [19:04:48] and that back room guy called MIT [19:04:51] something like that [19:07:19] Thanks again for the help, I'll be coding up several more value displays this evening for the coast / align downlist. Then I still have all the other do do. The ASCII layout is very tedious to make sure I don't lose track of the downlink words [19:08:13] Can't wait to get the HW emulation of the PIPA and CDUs going, most likely in the next month or so once I can see their values on the downlink [19:08:14] our telemetry client is buggy in high bitrate, so we can't figure it out either [19:09:22] I'd really like your AGC to do coasting integration [19:09:39] just would need CSM and LM state vectors [19:10:22] I wonder, does it try to do that in P00 without a padload? [19:10:34] is it throwing any errors like that? [19:11:19] in the padload the CSM and LM state vector times are set to all 3777s so that it will never try state vector integration before the the first uplink [19:11:27] 37777s* [19:11:32] No errors being thrown in P00. Only code I got was related to downlink to fast (1105). [19:11:38] hmm, ok [19:11:56] and you did a V37E 00E to get to P00, right? [19:12:02] or V96E [19:12:29] ah, haha [19:12:33] I forgot [19:12:36] TIME will also be 0 [19:13:26] I did V37E 00E, but I'll double check that later today. My AGC time is incrementing (up to about 5+ hours now). [19:14:14] Let me get uplink working in the next week or two so that I can get a padload installed, then let's talk through getting coasting integration running. [19:14:39] probably something else missing that prevents it from trying to use the coasting integration in P00 [19:14:40] I regularly use V37E 00E to get to P00 on my FPGA build, and have never seen a P00-related alarm pop up [19:14:57] same with standalone virtualagc [19:15:18] This has been my basic plan. Be able to see data, be able to upload data, then try to make it do something useful. [19:15:51] right [19:17:26] I probably am thinking too operational, there will be something missing to a blank LGC that just won't try to do that [21:29:31] night! [00:00:27] SteveH, you still around? [00:25:11] yeah, what's up. I'm trying to figure out what the position component of a state vector looks like. [00:40:00] Ron sent me an exciting email earlier and i wanted to share :D [00:40:06] The other thing is that so far I've been using the NARA research-room's  [00:40:06] microfilm scanner to pick-and-choose the drawings I wanted, or else to  [00:40:07] use a crummy flatbed scanner to mass-scan a bunch of aperture cards at  [00:40:08] super-low quality.  But now I've come to an arrangement with the  [00:40:08] archivists.  Instead of doing that, I'll become a "volunteer" and use  [00:40:09] their much better but restricted-to-personnel aperture-card scanner with  [00:40:10] its autofeeder to scan entire boxes of cards.  With luck, I'll be able  [00:40:10] to scan about one box of aperture cards a day.  It might take a couple  [00:40:11] of years of vacation days, but I'll get every available revision of  [00:40:12] every available Apollo and Gemini drawing.  (Assuming the paperwork goes  [00:40:12] through, and assuming I don't just bail on the whole thing.) [00:51:23] Wow! that is exciting. How many years to go through and index all that material once scanned? [00:58:30] oh man who knows [00:58:43] just in the Apollo stuff, if we include all of the NAA and Grumman and other drawings... [00:59:07] I cannot even imagine how much data that represents. Will Ron have enough storage space for all this? [00:59:20] there's roughly 2000 cards per box and... several hundred boxes [00:59:27] the internet archive is our friend :D [00:59:45] and I'm fine with buying him hard drives lol [01:00:32] Yeah, exactly. So maybe a a million cards give or take a few hundred thousand? [01:00:45] something like that, yes [01:01:46] the MIT stuff spans 46 boxes [01:01:58] so we'd almost certainly clear that out before moving on [01:02:22] there's a good chance that AEA schematics are in the lot somewhere, and those would be really cool to find [01:02:38] not in the MIT boxes, I mean, but hidden somewhere in the others [01:02:58] I have no idea what TRW's numbering scheme was [01:03:16] Oh, and to answer my question about position components of state vectors, they appear to be represented as a decimal fractional value with 10 significant figures. Resolution down to +/- 0.0000000001 [01:03:26] ah nice [01:03:43] uses a 28-bit magnitude with sign bit. 1 = 2 ^ 29 [01:04:40] Help with a TLA (three letter acronym) AEA??? [01:04:55] Abort Electronics Assembly, the computer in the AGS [01:05:07] which is Abort Guidance System, but you probably knew that one :) [01:05:35] Ah, okay. Only knew it as the AGS. Understand now. Multiple TLAs because having only one to identify something is boring... :D [01:05:43] hehehe [01:06:03] well "AGS" technically includes the accelerometers and gyros and things as well [01:06:09] it'd be like calling the AGC the PGNCS [01:06:12] gotcha [01:06:56] How many years does it take to learn all this, and what do I need to forget to make room for all the new knowledge? [01:07:44] well, this has consumed pretty much all of my free time for the past five years, so that's all I have to go on [01:07:52] and... just about everything else, but who needs all that other stuff :D [01:28:03] SteveH, if you haven't seen it, here is the index of aperture cards at Fort Worth: https://docs.google.com/spreadsheets/d/1DOwUA86ieQYosAoKf344AnlLbywgvx0-02Guc9StOfA/edit?usp=sharing [15:20:02] hey [15:25:08] hey Alex [15:29:21] very cool to finally have a solution for SSU burns [15:35:56] yeah, the Shuttle rendezvous profiles have their own trickiness as compared to Apollo [15:36:28] flying STS-88 right now to do a bit of ISS assembly [15:38:24] what I learned definitely applies to Gemini and Skylab rendezvous. So maybe it results in some launch window targeting tool [15:53:08] nice [15:53:59] Is it capable yet of calculating shuttle de-orbit burns? [15:55:03] no [15:55:20] although I also got the FDO Handbook for that part [15:55:32] and I found a document that has abotu 250 pages on deorbit calculations [15:56:34] maybe I'll implement that eventually [16:02:33] for STS-88 I've installed some addons to do the mission properly, so maybe I'll just keep going and do a deorbit [16:02:59] although I believe the entry stuff is being worked on in a development branch, so I don't have the latest state of SSU on that [17:44:10] morning! [00:22:35] hey SteveH [00:36:25] Hey [00:36:32] how's it going? [00:37:13] Going okay, just working on some display code. [00:38:01] nice [00:39:17] I've been thinking about "aftermarket" displays I want to add to the monitor UI, along with my decidedly non-original rope loading/dumping interface [00:40:05] I think I'm going to add an alarms panel, with two lights for each of the 11 alarm signals that come out to the test connector. one that shows current state, and one that latches on if it occurs [00:40:14] with a button below each to reset the latching light [00:40:58] does that sound reasonable? anything different you want there? or any additional panels that the original didn't have that you'd find useful? [00:43:18] Yeah that sounds reasonable. Basically adding the CH77 monitor. Had not thought of the manual reset, makes sense. [00:44:06] Just re-read and realized you were not specifically talking about CH77. Still think that would be useful too. [00:45:02] oh I already have CH77 working [00:45:21] but CH77 doesn't look at all of them and the AGC can reset it itself if it wants to [00:47:58] hmm... speaking of ch77 though, I should probably split the parity light into a "fixed parity" light and an "erasable parity" light [00:48:07] so 12 pairs [17:45:32] morning! [17:58:01] hey [17:58:05] what's up? [17:59:46] finding many bugs in my MFD [18:00:28] but no time to fix them now. Have to go. Cya! [17:55:26] morning! [17:55:30] says Mike to nobody [17:52:19] morning! [18:09:51] hey [18:20:10] what's up? [18:20:40] checklists for STS-88 aren't available. So I have been really struggling with grappling Zarya [18:20:56] and I might have docked Unity the wrong way around to the Shuttle [18:22:16] hahahaha oh no [18:22:49] PMA-1 and 2 look so similar [18:23:00] but they probably have very different docking mechanisms [18:23:09] so, I think I'll move on to something else [18:24:07] I want to do a mission with lots of RMS operations [18:25:48] RMS? [18:25:50] for which there are checklists available [18:25:55] robot arm [18:26:05] Shuttle Remote Manipulator System [18:26:08] Canadarm [18:26:10] many names :D [18:26:19] oh! right :D [18:26:59] the arm supports auto sequences, but I think manually moving it around is more fun [18:27:08] the off-nominal procedures usually have it all step by step [18:28:32] that does sound a lot more fun [18:30:01] and for all the later missions there should be addons with the payload [18:30:12] but not necessarily realistic launch scenarios [18:30:18] might have to make those myself [18:34:51] have to go again. Cya! [21:47:10] waves [22:31:13] hey Thymo [22:31:32] Hey, watching The Orbville atm [22:31:42] s/b/v [22:31:55] s/vv/v [22:32:41] nice [11:25:41] Hello, could someone help me with something? I've just reached MCC-1 in Apollo 11 and it's been scrubbed. Is there any way to work out why it was scrubbed? [14:16:02] .tell msligo Sorry for not being around. MCC-1 gets often scrubbed due to small DV. MCC-2 and 4 are preferred execution points [18:22:44] morning! [18:25:33] hey Mike [18:48:56] what's up? [18:50:48] trying to create a STS-129 scenario [18:51:14] with the full ISS, which apparently consists of 250 individual vessels and 3000 lines of stuff in the scenario [18:51:49] STS-129 was about the least supported mission, not sure why I want to do this... [18:52:22] and now I just deleted everything post STS-129 from the ISS for this scenario and hope it still loads [18:58:17] hahahaha [18:58:29] wow, 250 vessels, that is crazy [19:01:19] whoever created the japanese module made every single thing a separate vessel [19:01:26] like batteries even [19:01:37] oh jeez [19:13:00] not necessarily japanesse, just was saved in a JAXA folder, maybe one of the Shuttle missions that brought up JAXA hardware did EVAs to replace batteries there [19:13:17] so they are all separate vessels so that e.g. individual batteries can be changed [19:13:55] still, quite a mad setup I have now [19:14:44] haha, how the frame rate dips when I move viewpoint around [19:15:22] and I think I managed to move the ISS to where it should be with the scenario editor. Better than having to edit 250 state vectors manually... [19:22:03] and I chose STS-129 over other missions based on the sizes of its checklist for robot arm operations :D [19:22:07] size* [19:39:42] hahahaha oh shit [19:39:46] they all of their own state vectors? [19:39:49] that is terrifying [19:40:06] and yes of course, more robot = more better [19:41:46] well, they have their own state vector, but they also show if they are docked or attached to something [19:42:14] so you probably would only have to give the first vessel in a scenario that is docked to something else a full state vector [19:42:26] and everything else will derive its position from that [19:43:04] but what I did was have the default ISS (single vessel) in the scenario, start Orbiter paused, move over the full ISS to the position of the default one, close scenario [19:43:19] and then copy&paste all the scenario lines from the quicksave to the launch scenario [19:43:39] that seems to have worked. The attitude of the ISS is wrong, but it can fix that iseful [19:43:42] itself* [20:00:38] mm, makes sense [20:05:25] seems some payloads are a bit far back in the payload bay right now, but otherwise the scenario is good. Creating a scenario from almost scratch is tough! [20:05:37] for NASSP it's all the padloads that are difficult [20:05:43] the rest is easy [20:21:39] yeah I guess there is a lot more moving parts to be concerned with with shuttle [21:23:16] night! [18:10:37] morning! [18:15:04] hey [18:28:29] what's up? [18:29:52] still working on that STS-129 scenario, lol [18:30:24] today I managed to break the scenario for a while. And I think I crashed Windows because of it [18:30:38] hahahaha [18:30:40] impressive [18:30:52] the last problem is a message getting spammed in the Orbiter log [18:31:01] twice every timestep, which I believe affects performance [18:31:29] also, there are lots of "mesh is missing" messages in the log, but apparently they are harmless?! [18:31:47] but if those things are resolved, then I can launch [18:32:09] oh, and I fixed a payload issue by changing a 1 to a -1 in a ini file :D [18:32:43] so yeah, creating scenarios with the full ISS and a full payload bay is totally easy [18:36:22] and now it's crashing again [18:37:31] getting the details right is difficult. PMA-3 for example has been moved around for like 10 times by now [18:41:10] but it looks really nice as compared to the default ISS [18:42:44] hahaha [18:42:59] twice a timestep, yes I can see how that affects performance [18:43:19] open file, close file [18:43:42] ouch [18:43:56] that's surely what it has to do for that [18:44:21] if it doesn't get fixed I'll just remove the SSRMS temporarily [18:44:50] I know that it's the fault of the station arm [18:44:57] wasn't easy to find out, haha [18:49:02] lol [18:49:07] so many acronyms I am having to look up :P [18:49:55] I don't even what half the things in the SSU mission files are [18:49:59] even know* [18:50:16] UseExtAL=TRUE [18:50:20] sure, why not [18:50:24] can't hurt to have that [18:55:08] hahaha [04:02:46] Hello everyone. I'm currently trying to update the ECS system to make the fluid flow simulations more accurate and more stable. Does anyone know whether we have access to original blueprints for the ECS system? The ECS schematics available in the AOH and LM Systems Handbook are really helpful, but it would be really useful if I could know things like the length and diameter of pipes, what materials they're made from, and the coordinate [04:05:39] .tell indy91 Ahh ok, so I should just ignore MCC-1 and continue to MCC-2? Even so, it would be nice to know why it was scrubbed, is there a way to find out? Where can I find out how the debugging options work? [06:34:34] Actually never mind about blueprints, I just found the Structures section of the LM Systems Handbook [06:53:08] hey msligo [06:54:23] it's definitely possible to get original Grumman blueprints for this stuff... with the caveat that you have to know the drawing number in advance, and be willing to pay $4 per page (for now) [06:54:36] there's another document that might be helpful, if I can remember what it's called [06:56:46] ah, here [06:56:53] Lunar Module Elementary Functional Diagrams [06:56:55] https://web.archive.org/web/20061103215700/http://ntrs.nasa.gov:80/archive/nasa/casi.ntrs.nasa.gov/19710070889_1971070889.pdf [06:58:04] and https://web.archive.org/web/20060104172247/http://ntrs.nasa.gov:80/archive/nasa/casi.ntrs.nasa.gov/19710070891_1971070891.pdf [06:58:20] there's a good level of LM detail in those [06:59:12] I also had LDW 330-55000 scanned a while back, which were the Grumman Level III drawings of the LM ECS [06:59:18] let me see if I can dig that up [07:07:03] okay yeah found it [07:07:19] let me organize this and make it presentable... shouldn't be more than a half hour or so [07:20:57] wow! thanks thewonderidiot, this looks great! [07:22:45] sure thing :) [07:22:56] I'm almost done sorting the LDW 330-55000 scans [07:31:40] okay, sorting done, just need to generate a PDF from all of these images [07:37:30] I really thought I had finished this little project a while ago [07:46:43] ugh, the thing doesn't want to make a decent pdf [07:46:45] so close... [07:48:25] okay, not perfect but this should at least be usable [07:50:04] msligo, https://drive.google.com/open?id=146-nbsik0phptDBMwWEuX8tQ3X9t1SBa [07:50:06] enjoy! [07:50:41] those are the original Grumman level 3 schematics for the ECS... all part numbers in there (LDWxxxxx, LSCxxxxx, things like that) are other drawings that can probably be scanned, if more detail is needed [07:51:53] you might need to download it; the drive viewer doesn't let you zoom in too far [08:09:15] fantastic, thank you so much! [09:00:26] How were all of the original Apollo documents organised? Was there some sort of structure/numbering system that made it easy to track down documents? Is a list of all the original documents available anywhere? [12:51:25] . [14:16:41] .tell msligo The answer is always the same, a maneuver gets scrubbed if the DV for it is below a certain threshold. I don't think any Apollo mission actually performed the MCC-1 maneuver. So yeah, you can basically ignore MCC-1. [18:22:19] morning! [18:22:50] hey Mike [18:23:01] what's up? [18:23:20] writing a manual for my Shuttle MFD [18:24:56] oh and I figured out the solution for one addon spamming messages in the Orbiter log. Didn't realize the source code was available, so I just myself a version that didn't do that. [18:45:13] nice [18:46:53] and I'd like to know more about the rendezvous profile that Dragon is going to fly on Saturday [18:47:21] Maybe the SpaceX press kit will have some things on that, but it hasn't been released yet [18:50:03] and I tried a STS-129 launch with everything fixed, but the orbit isn't quite right. Either the orbit of the ISS or Shuttle, but my guess at this point is Shuttle. [18:50:28] SSU doesn't do very good steering into orbit yet [19:13:31] hmm [19:13:33] how far off is it? [19:19:43] oh at insertion it's great [19:19:52] 0.1° plane difference [19:20:19] but it should be much more difference in longitude of ascending node due to the differential nodal regression [19:20:51] I've looked at a different ISS TLE, but it wouldn't make much of a difference [19:21:26] Shuttle launch is in-plane, so even lack of yaw steering shouldn't give so bad results [19:21:48] a plane change maneuver would be about 150 ft/s, which is way too much [19:22:48] maybe I just got lucky with SSU on my last flight using non-spherical gravity [19:46:05] hmm, interesting [20:16:03] well I cheated the ISS orbit a bit again and will now try to fly the rest of the mission [20:17:34] should be fun to watch the high resolution ISS appear in the distance :D [20:17:44] I'll notice when the frame rate starts dropping [20:47:44] hahaha [20:53:41] press kit is out, and it's the most underwhelming thing it could be [20:53:46] 2 pages, nothing new [20:55:18] the press kit of the first mission of the Cargo Dragon was 33 pages, haha [20:55:25] first mission to ISS* [21:12:29] oh wow, that is disappointing [21:14:43] technical details are boring, obivously [21:18:25] yeah I get that [21:18:28] I hate that technical stuff [21:20:03] well, Hans Koenigsmann from SpaceX just said something about "3 burns" in the press conference, so now I already know much more :D [21:20:48] I'm mostly interested in the type of rendezvous. Coelliptic like Gemini, Apollo and Dragon 1, or Stable Orbit Rendezvous like the Shuttle [21:21:28] I'm sure I can figure it out by following the mission progress [21:31:11] good night! [23:02:51] . [23:05:10] .tell indy91 Ahh ok, so MCC-1 is a trajectory correction manouvre? I was under the impression that it was a decision to abort the mission. When it said it was scrubbed I thought MCC was aborting the whole mission and returning me to Earth. That makes a lot more sense now. [23:18:39] hey msligo [23:18:58] if only it were so easy that there was a big listing of documents, haha [23:19:06] a lot of this stuff we just stumble across through luck [23:35:41] also yes, that's right, scrubbing MCC-1 is just scrubbing the first midcourse correction maneuver, not the mission -- it means your mission so far is going well [23:45:12] Fantastic, that's great news. I was thinking "why? What did I do wrong? Am I going to crash into the moon or something?" [23:46:57] with regards to documentation, there might not be a list, but surely there must have been some sort of structure that NASA/Gruuman/NA used to keep track of all their documents. You said something about Level 3 engineering documents, what are they, and what are the other Levels? [23:52:09] no idea [23:52:24] we have not found a document that presents such information [23:52:28] at least as far as I know [23:52:34] it's a Grumman-specific thing I think [23:52:55] we found the level 3 drawings because the system handbooks reference them [23:56:33] each organization did documentation very differently [07:40:36] indy91, you're here early! [07:41:25] Didn't want to communicate with msligo via Guenter all the time, haha [07:41:28] but now he isn't here [07:43:22] maybe tomorrow, I'll be here at the same time as well, for the SpaceX launch [07:43:33] awesome :D [07:43:41] luckily I have time then, I'll be busy for most of Saturday [07:46:27] nice [07:46:33] yeah this will be a fun launch to watch [07:47:24] I'm really excited for the in-flight abort test too [07:49:12] yeah, should be fun [15:39:02] hey [16:18:31] HEY [16:18:37] hey* [16:31:40] fun launch tomorrow, but I guess it's at terrible o'clock your time [17:08:47] ah yeah [17:09:15] well I work early tomorrow so definitely be sleeping then :D [17:11:08] I'd like to set up a realistic rendezvous profile for the Dragon mission with my new MFD, but I really haven't able to find anything about the profile they will be flying [17:12:38] and also if that is the same profile that the manned missions will use [17:12:59] I believe most cargo vehicles flying to the ISS use coelliptic orbits, approaching the ISS step by step [17:42:59] morning! [18:17:46] hey Mike [21:16:13] night! [07:02:19] morning! [07:04:36] good morning! :D [07:05:03] you have both stream links? [07:08:58] uhh [07:09:02] NASA and SpaceX? [07:09:21] spacex and unlisted technical stream with the launch net: https://www.youtube.com/watch?v=L_7lgQwIffo [07:09:38] LES was just armed [07:10:35] ah [07:10:58] the second one can be reached, when you choose "change camera" on Youtube [07:11:19] rather quiet right now :D [07:11:59] aha, I see [07:12:17] I forgot about the change camera button :P [07:12:33] it's rarely there, haha [07:12:59] I like the new passenger they added [07:13:13] must be Mission Specialist 1 [07:13:19] hehehe [07:14:39] and they're reusing her for the in-flight abort test! [07:14:47] along, I think, with this core, assuming it lands [07:15:04] although I might be mixing that up with another recently launched core [07:15:49] yep, definitely wrong [07:16:00] oh, i meant the blue Earth ball like thing [07:16:20] oh I totally missed that [07:16:45] I already knew about the dummy [07:16:52] lol [07:17:02] who cares about the dummy. there's a blue sphere! [07:17:56] Zero G indicator, like the Soyuz always have [07:27:15] did you figure any more out about the trajectory? [07:32:17] nope [07:38:58] the Apollo astronauts would have been pissed about that interface :P [07:39:44] David Scott might have liked it [07:40:25] absurdity of the day: Apollo Flight Journal is hosted on NASA servers. [07:40:33] it used to link to NTRS for many documents [07:40:41] some of which were removed in 2013, of course [07:40:49] so until now it had a bunch of dead links [07:41:06] that's not fixed, by linking to the archive.org versions of the documents [07:41:09] that's now* [07:41:12] hahahahaha [07:41:15] amazing [07:41:44] did you suggest that? [07:42:06] haha, no [07:42:32] that makes it even better :D [07:42:44] The AFJ is mostly run by David Woods, who is not working for NASA, they just host it. [07:42:51] I see [07:42:52] so it's not really NASA running it directly, but still [07:43:11] still very silly [07:43:22] yep [07:47:34] I like their new mission progress meter at the bottom [07:50:03] bit more difficult to read I think [07:50:57] the main stream doesn't like me, always buffers [07:51:06] NASA TV seems fine [07:53:56] is the second stage nozzle always glowing so much? [07:54:20] I think so [07:54:52] I was just about to say, I'm surprised they're not showing more internal shots [07:55:14] hehehe, I also like the second passenger :d [07:55:17] :D [07:58:52] 197km, 27171 km/h [07:59:57] too slow to be inertial [08:00:03] velocity [08:00:47] and there it is floating around! [08:00:56] :D [08:03:17] so it'll be there in 3 hours [08:03:34] ? [08:03:42] or is that 27 hours [08:04:57] 27 [08:05:16] I had read something about ca. 30 hours, so that makes sense [08:05:24] that makes more sense [08:05:37] 6am EST on Sunday [08:05:42] I guess [08:05:44] they were saying "tomorrow" and it is 12:05am here, so I got confused :P [08:05:51] which tomorrow? [08:06:05] tomorrow in both GMT, CET and EST :D [08:06:10] in all* [08:07:14] but not Western A Day Behind Timezone or whatever you are in [08:08:06] lol [08:10:01] speaking of [08:10:10] I am going to make it become tomorrow [08:10:12] goodnight! [08:11:06] night! [20:09:39] So I just found out NASSP's gitignore file is horribly broken. Basically all the source files are ignored. [20:10:01] Of course you don't notice this until you try to add a new one [20:28:02] haha, nice [20:29:01] Also we had a line so "core" would be ignored. That's the agc coredumps, but those have been disabled in NASSP since forever. :p [10:02:44] Morning [10:22:54] hey [11:04:10] Thymo, I've seen your PR. Why again did you remove core files from the gitignore? I don't think we would add core files to the repo, so shouldn't they be ignored? [18:13:50] morning! [18:37:48] hey Mike [18:40:14] what's up? [18:43:28] did a bit more Shuttle flying and of course watched the Dragon docking [18:44:04] I need to go back and find a video of that -- the docking was too much in the middle of the night for me to stay up and watch it [18:44:11] or I'd be suffering at work tomorrow, haha [18:46:11] yeah [18:46:14] should be easy to find [18:46:43] like here: http://www.space-multimedia.nl.eu.org/index.php?option=com_content&view=article&id=6663 [18:47:00] there are probably some official videos as well [18:51:15] nice, thanks :D [20:38:51] indy91: I already was at work by the time you sent your message. :) [20:39:08] We don't generate the core files, we have that turned off. We pass a null pointer for the filename, so it doesn't do anything. [20:40:06] Actually. We do have that button to do a coredump in the MFD, is that what is saved as the "core" file? [20:45:24] yeah [20:45:36] does the standalone Virtual AGC do periodic core dumps? [20:47:56] ah yeah, you mentioned that in the PR [20:47:58] every 15 seconds [20:48:21] and I guess we don't use the Virtual AGC core file input, because we do the saving/loading on our own [20:49:56] and only use the core files when we generate them manually by button press in the PAMFD [20:50:18] and that's probably why it should still be ignored [20:50:34] we can generate core files, but won't ever commit them [20:50:47] so it should still be in the gitignore [20:51:27] Yes. When you initialize the engine you specify the file it should go to for the periodic dumps. [20:51:41] I hadn't considered we do manual dumps through the MFD. [20:52:59] I made some for the standalone Virtual AGC to load. Shortly before lunar landing etc. [20:53:21] I know. PR updated. [20:53:40] I only half understand that other half of the PR, but it sounds reasonable :D [20:54:33] merged [20:54:44] If you ignore a certain directory, all of its childeren are ignored too without being able to negate it later. The only way is to go dir/* and then exclude the directory that should still be tracked. [20:55:45] so that the source code of other addons is ignored [20:56:14] Well. We had an ignore on Orbitersdk/. NASSP is in Orbitersdk/sample/Project Apollo [20:56:24] So our source files were ignored too. [20:56:34] ah, ok [20:57:01] At first I though I was going crazy because git didn't see my new source files. [20:57:34] I just had accepted that I had to add all new files manually, haha [20:57:50] with a -f to force it through [20:59:03] Haha. Well now you no longer have to! [20:59:58] good to know [21:08:00] good night! [17:46:54] morning! [17:59:31] hey Mike [17:59:39] what's up? [18:00:10] settling in to work, you? [18:00:44] finally docked to the ISS, flying STS-129 [18:01:15] what a pain to set up the ISS was. I thought I was all done, then I had to edit around in the scenario to make docking work [18:04:27] hahaha oh no [18:05:54] PMA-2 docking is broken, the actual docking port in Orbiter is on Harmony [18:05:58] ... of course [18:06:29] good thing that we didn't tell the Dragon yesterday that PMA-2 docking is broken [18:06:37] well, it has an adapter, maybe that fixes it [18:06:45] it's probably better that the astronauts don't know [18:09:27] but I'm finally there, yay. Looked really good, but I am still not sure that it was worth the effort setting it all up [18:12:52] next I'll try to launch one of the default SSU scenarios so that I can use it for a tutorial for my MFD [18:14:43] hehehe [18:15:10] unrelated, but [18:15:42] have you seen Apollo 11 yet? is it out in Germany? [18:15:50] the documentary? [18:15:52] yep [18:16:08] I have not seen it [18:16:43] you need to, it's incredible [18:17:59] I think I'm going to go see it again this weekend, haha [18:18:28] not sure it's available here [18:20:55] yeah,I am not finding anything [18:21:07] there aren't many IMAX cinemas in Germany anyway [18:23:22] not anywhere in Europe yet it seems [18:24:40] there is an IMAX in a tech museum, I bet they will it show there at some point. But it's quite far away from moe [18:24:42] me* [18:26:06] I'm reading a rumour about a release in Germany in May [18:37:55] May? oh man that's rude [18:44:00] I wonder why they're staggering the release like that :/ [19:02:04] probably difficult to do a worldwide release if you aren't Walt Disney Pictures [19:02:16] that's fair I guess [19:40:15] Evening! [19:40:46] hey [19:41:11] Finally was able to take my C++ test today. [19:41:40] the one where the program didn't work? [19:42:03] Yeah. [19:42:23] and this time it all worked great? :D [19:42:27] Still had to do it on a spare account because they forgot to sign me up in the system. :p [19:42:37] ah, great [19:43:23] And it was Win7 in a VM. Add a bulky IDE on top of that and you end up being faster than the linter and code generator. [19:43:40] But all in all, it worked and went pretty well. [19:43:49] Almost handed it in with a SEGFAULT in it. [19:46:28] probably wouldn't get you bonus points [19:47:16] Generally not no. [19:48:01] There's two things that I know didn't score full points on. One is that I used a signed integer where I could have used an unsinged int for an id. The other is that segfault situation. [19:49:26] I had a list of a bunch of objects of class A. On one of those objects I had to call a function that was part of B (a derived class of A), but I couldn't figure out how to cast a shared_ptr of A to B. [19:51:14] auto *ptr = really_cast_damnit(A); [19:51:18] something like that right? :P [19:51:25] Something like that. [19:51:48] At some point I had reinterpret_pointer_cast. [19:52:12] It compiled. But gave me a nice 0xC0000005 [19:53:11] according to our flight software that is an invalid dwell length :P [19:55:06] really_cast_damnit must be C++ 17, never heard that before :D [19:55:57] Well, for windows it's just a way to tell you to that you're code sucks [19:55:58] s/you're/your [19:55:59] Guenter! [19:56:00] s/you're/your/ [19:56:12] lol [19:57:31] Laptop wifi went down the drain. [21:08:56] night! [22:15:20] . [22:23:32] .tell indy91 Sorry indy91, I was away for a few days. I'm busy tonight, but I'll be online between 1100 and 1330 UTC Wed 6th March. [17:49:37] morning! [18:53:42] Hey Mike [19:02:55] hey, what's up? [19:04:17] hey [19:04:33] right [19:04:39] just here to turn off my PC :P [19:04:40] bye! [19:07:02] Haha [19:07:50] I've mostly been working on school stuff today. Still implementing stuff for my own shell and slowly starting to get ready to write my own compiler. [19:08:10] Probably will mess around with the IoT board in a bit. [19:09:13] Lots of fun stuff this period. But it does keep me busy. [19:10:04] I also want to take a look at my tooling. I'd like to be able to develop in vim without getting a headache. [19:11:24] hahaha [19:11:28] yes, vim is great :D [19:11:41] It's a great editor. [19:11:49] Now I need it to be a great IDE. [19:12:18] I need better syntax highlighting for more languages and a linter. [19:12:39] Then an easy way to compile and run stuff would be great. [19:15:42] can't really help with most of that... but I am a big fan of vim+tmux, which might help a bit with the compilation/running side? [19:16:18] it's less about making vim do these things, and making it way more seamless to switch between vim and terminals [19:16:42] Yeah. I think tmux will help. [19:17:05] I've never used it but I know that it's pretty cool as far as I've seen and heard. [19:17:13] it's great [19:17:35] akin to a tiling window manager, but just in the terminal [19:17:56] I always settled for screen. It did the job as far as connecting to uart devices and quickly having a terminal screen that I can background. [19:17:56] I regularly have 2-3 vim instances up, and 1-2 terminals up, all tiled in the same console [19:18:30] I usually do a vsplit in vim and have the source and header file side by side. [19:19:09] Or like stuff I'm working on on one side and stuff I'm referencing on the other. [19:19:11] the nice thing about tmux/vim integration is that the hotkeys for switching between vim splits and switching out of vim into other panes like terminals the same [19:19:19] so vim splits just become like tmux panes [19:19:41] just ctrl+hjkl to move between things, be they terminals or splits [19:20:13] Sounds great [19:20:25] combined with turning the caps lock key into ctrl, you have super fast home row navigation [19:21:04] Is replacing caps a vim thing? Or do you still go into all caps writing? [19:21:30] no, I never have caps lock enabled... I don't think I have a way to enable it [19:21:44] capitalizing things is a vim action though, gU [19:21:58] so you can highlight a bunch of stuff with v/V and caps it all with gU [19:22:50] or give it motions, like gUiw [19:27:03] so I replace caps with ctrl at the OS level, normally [19:27:22] plus it makes things like ctrl-C/ctrl-V so much easier to do [19:28:23] So pressing Ctrl on your system toggles caps? [19:28:29] nope [19:28:44] like I said, I don't think I have a way to get into caps lock, because I never use it [19:28:47] ctrl is also ctrl [19:29:08] Okay, so you just mapped an extra ctrl key. Got it. [19:29:17] yup [19:29:29] a key that far more deserves to be on the home row than friggin caps lock :P [19:29:52] True. 9/10 times I press caps lock it's accidental. [19:33:07] Hey thewonderidiot - get a minute for a quick question? [19:33:30] hey, sure, what's up? [19:35:02] Need a second opinion on some troubleshooting I'm doing for uplink. Got uplink working but think my pulse widths are too short on UPL0 / UPL1. Looks like INLNKM/INLNKP are gated and clocked by F04A in A19. I think the pulse width would need to be 2x the F04 frequency correct? [19:36:03] I have really bad data drop out issues right now. Think my input pulse widths are currently too short and some bits are being missed by the A19 circuit. [19:37:13] hmmm [19:37:55] it's not the pulse width that that circuit is controlling as much as it is the bit rate [19:38:47] whenever you receive an inbit, the funky looking "uplink too fast" flip-flop gets set, and this gates any further inbits until the next F04A pulse [19:38:52] Yeah, have not found a timing info for the uplink. Looks like the UPL0/UPL1 signal needs to be held long enough for the FF triggered by F04A to enable the gates for INLNK [19:39:04] so it doesn't care how wide the pulses are, but the fact that you can only have one per F04A [19:39:30] F04A resets the flip-flop to allow the next bit to come in [19:39:59] per the symbolic listing information, "Rejection takes place if a 6400 pps pulse has not occurred since the previous input was received" [19:41:05] in the LM, the uplink rate was 1.1KPPS max [19:41:19] minimum time between words 0.1 seconds [19:41:53] Yeah been through all that, I know the bit rate is less than 6400pps but still get bad reception. My pulse widths are less than 100us right now. [19:41:54] original pulse width was... 3-5 microseconds [19:42:04] okay. [19:42:57] I'm not sure I ever exercised uplink fully in simulation, so it's very possible that I have a wiring error somewhere [19:43:06] Is there a single doc source for this? Been trying to locate specific signal timing for uplink and coming up short other than the 6400pps spec. [19:43:19] http://www.ibiblio.org/apollo/klabs/history/lm-icd/10_uplink_sh-86.pdf [19:43:52] I successfully receive between 1 and 10 words of data and then get an 1106 alarm so I think the wiring is correct but I cannot get a full V71 sequence to be received clean [19:45:05] Able to see this in the downlink. [19:46:46] hmm [19:47:37] very weird [19:47:57] That reference is perfect. I'm definitely trying to run the pps much faster than 1100 so I'll try slowing that down when I get home tonight. [19:49:00] I've tried time between words of 50 to 500 ms and that didn't fix it so I'll set it back to the 100ms in the Grumman spec [19:49:33] I almost wonder if the problem is the other way around -- that maybe your pulses are wide enough that if one is poorly timed, it's double-counted [19:50:18] hmmm [19:50:21] F04 is at 151us if my math is correct. [19:50:51] 156.25, yeah [19:51:17] I am running pulses of about 90us every 300 - 500 us and still get 1106 [19:51:49] I'll try closer to the 900us of the Grumman spec and see what happens [19:52:36] ohhhh wait a second [19:53:15] yes okay [19:53:27] I need to look at the schematic some more. Refering to your A19 it looks like F04A goes to the input of the tripple input gates for INLNK* [19:53:29] the 3-5us pulse width is what's important here [19:53:53] Okay [19:54:07] following through the schematics, the input pin becomes UPL0 becomes UPL0/ which, when inlink is not gated, directly becomes INLNKM [19:54:23] so it's more-or-less a direct path into the counter cell request flip-flop [19:54:42] Ah, so at 90us my INLNK pulses are huge [19:54:57] if your pulse width is wider than 1 MCT (11.7us), then you're very likely to double-request inbits [19:55:22] because it'll just set the counter cell again after the count happens [19:56:05] Okay, that will be pretty easy for me to try tonight. Need to run to a meeting in a few minutes. [19:57:05] I'll catch up with ya later this evening my time and let you know what happens. Thanks! I see now that UPL0/1 is a direct path to the INLNK pulses. makes sense. [19:58:08] cool! hopefully it works :D [21:35:10] Installing tmux right now. [21:35:23] Are you using any noteworthy vim plugins Mike? [23:33:54] Hi everyone. I've run into a strange problem. I'm trying to obtain accurate x coordinates for various components on the LM, and the blueprints don't seem to be to scale. [23:34:42] I'm looking at page 27 of the LM Systems Handbook here: https://www.ibiblio.org/apollo/Documents/HSI-208818.pdf [23:35:53] This blueprint has 4 reference stations marked, at x=154, 200, 233, and 254 inches. I've printed off the diagram, and I'm trying to obtain an inches/cm conversion scale [23:37:48] 4 reference stations means I can make 6 separate measurements, but the problem is that these measurements are all over the place. The smallest result is 8.6 in/cm, the largest is 11.3 in/cm, the mean is 9.8 in/cm, and the standard deviation is 0.89 in/cm [23:39:00] Since the LM itself is about 35 cm high on my page, a STD of 0.89 seems to imply that there's an uncertainty of about 31 inches in the overall height of the LM, which seems excessive [23:40:25] It also doesn't seem to be an artifact of the printing process, since I took the same measurements in in/pixel on my computer, and I got identical results [23:41:05] The only two explanations I can come up with is that either the original blueprint wasn't drawn to scale, or something went wrong in the scanning process. Perhaps the image was squished or something? [00:36:12] msligo, the systems handbooks were created by the flight control division for use by flight controllers [00:36:38] they were made in a lot of cases using original material, like original blueprints, but everything in them is redrawn from other materials, and sometimes there were mistakes in the conversion [00:37:43] we've run into problems in the system handbooks before that we were only able to resolve by going to originating organization documentation, e.g. the elementary functional diagrams from Grumman [00:38:01] ahh right, ok. [00:38:17] Do you have any suggestion for how I might find x-axis coordinates for LM components? [00:39:01] not sure offhand -- I haven't done a whole lot with whole vehicle stuff, I mostly focus on just the AGC [00:39:05] so I'm not sure what is online [00:39:21] the original blueprints from Grumman are almost surely in the national archives, if you can figure out what the drawing number is [00:39:32] and sometimes the systems handbooks do say what their original source is [00:39:38] so that could be one way to find it [00:40:18] ok, I'll take a look there, thank you! [00:43:37] different versions of the handbooks also are frequently slightly different; sometimes later versions can have old errors fixed, or new errors introduced [00:47:34] Could you show me an example of accessing a blueprint for which you know the number? [00:47:55] Do you just put the blueprint number into the national archives search box? [00:48:37] no, it's a bit more manual than that, sadly [00:49:19] the way it works is you send an email to ftworth.archives@nara.gov, asking if they have the drawing in their "RG 255 Apollo Drawings collection" [00:49:40] they can scan it for you if they have it, but it is a bit expensive -- $4 per image [00:50:00] and wide drawings like the one you're referring to can sometimes be broken into 2-3 images [00:50:21] anyways, if they scan it, you can either mail them a check or call them with a credit card number, and then they'll email you the scans [00:51:09] Ron Burkey of VirtualAGC is working on becoming a volunteer there, in which case there's a possibility that we'll be able to digitize the whole darn collection for free, but there's going to be an initial focus on MIT things like the AGC, so I'm not sure when or if he'd get around to digitizing all of the Grumman stuff [00:51:11] hmm ok. Is it a problem if I'm not a US citizen? (I'm Australia) [00:51:15] *Australian [00:51:28] I'm not sure! haha [00:51:40] it's worth a shot, I'd say [00:51:53] haha ok. Any advice on finding blueprint numbers? [00:52:32] Grumman numbers are mostly going to be of the form LDW-XXX-YYYYY or LIS-XXX-YYYYY, or something like that [00:52:39] so keep an eye out for things that look like that [00:52:58] systems handbooks are good starting points, as are the level III drawings [00:53:15] sometimes googling known drawing numbers will lead you to others [00:53:51] and assembly drawings typically list out all of their component part/subassembly drawings, so if you can get an assembly drawing for what you're looking at you can get lots of numbers that way [00:53:53] also [00:54:15] https://docs.google.com/spreadsheets/d/1DOwUA86ieQYosAoKf344AnlLbywgvx0-02Guc9StOfA/edit?usp=sharing [00:54:38] that's a rough index of all of the drawings they have -- at the resolution of the number of the first and last card in every box (there's approximately 2000 cards per box) [00:55:27] oh wow, are those all the documents related to apollo? (not just Grumman?) [00:55:36] and it looks like they have, what, 160 boxes with LDW cards? so literally hundreds of thousands of drawings just from Grumman [00:55:55] yeah, I know for a fact that Raytheon, Grumman, North American, and MIT are all represented here [00:56:17] I don't recognize all of the number formats but I imagine it is a very large percentage of the original blueprints for the whole program [00:56:24] wow, that's crazy [00:56:30] yeah, it's fantastic :D [00:56:42] is it just blueprints, or does it include handbook/operations manuals/etc? [00:57:00] we've extracted nearly 100% of the original AGC and DSKY blueprints, both mechanical and electrical, over the past few months [00:57:14] these aperture cards are almost entirely blueprints [00:57:26] although there are occasional procedure things, like assembly/test [00:57:37] the handbooks and whatnot are stored there in physical paper form [00:57:39] wow [00:57:59] we have much less complete indices for those [00:58:56] Is there any sort of centralised place where apollo historians are keeping a database of this sort of stuff? Not necessarily just NASSP developers. [00:59:12] not really that I know of [01:00:45] If there was a small possibility that I might find myself in the US later this year. Is it possible for someone to walk in off the street and look through these documents? Or do you have to be a volunteer there? [01:01:39] even volunteers can't necessarily just look through things; anybody can go there for research, but you have to let them know ahead of time which boxes you want to see, so they can fetch them from storage for you [01:01:48] which can be tricky if you don't know what exactly you're looking for [01:02:29] there is a much higher level index of their whole RG 255 (NASA) collection, let me find it [01:03:00] https://www.ibiblio.org/apollo/NARA-SW/Rg255-1.pdf [01:03:20] Ron wrote a bunch about his process of working at NARA here: https://www.ibiblio.org/apollo/QuestForInfo.html [01:05:55] awesome, I'll have a read through all of this. Thanks for all your help [01:06:15] my pleasure :D [01:08:28] http://heroicrelics.org/info/lm/lm-4/LM-4%20Structural.pdf [01:08:35] this has many LDW numbers in it [01:08:41] some might be useful? [01:09:30] yeah this looks like a really good starting place for structural assemblies [01:16:10] Hey Mike, The shorter UPL pulses did the trick. Now have reliable uplink and downlink working. Running a 1us wide UPL0/1 pulse and everything is happy. [01:16:36] awesome!! :D [01:16:49] that is really really cool [01:17:37] Screenshot of coast / align downling. About 80% complete. Still need to add RR and LR as well as DAP. Also need to fix some unit conversions. https://drive.google.com/open?id=1hIi6xDPcfot7eAvM3-8T0s_VelPAkbUW [01:18:02] oh man [01:18:04] very nice [01:18:40] And a shot of the update list showing the UPBUFF values. This is from the first V71 of the Apollo 16 e-load: https://drive.google.com/open?id=1TmuupzB8dRKhGAwEV2iD6CkQVi1Sr3tw [01:19:48] Now I understand why some of the other up/down count inputs were specified at 1-3us (like PIPA) since they directly drive the counter signals. [01:19:53] oh neat [01:20:14] yeah, the possibility of a wide pulse being double counted hadn't occurred to me before earlier today [01:20:25] interesting that they didn't have any real protections against such a thing happening [01:20:48] Since these inputs were originally transformer coupled, generating narrow pulses would have been natural. [01:21:04] oh true [01:22:08] I figure I have about 20 hours into the first downlist (coast / align) the others will go faster since they duplicate a lot of the same info. I'll be chasing unit conversions for a while though. [01:23:05] yeah for sure [01:24:00] Next on my list is to get the PIPA and gyro angle inputs working. Still working off a single PIC controller. I'll get a few more running as one-offs that I need to fabricate the box to hold them all. [01:24:39] Thanks again for the help. You saved me at least a few days of banging my head against the wall! [01:32:34] sure thing! :D [01:32:44] I've been working on the mechanical and electrical design for the monitor lately [01:33:13] which annoyingly because of the way MIT drew the schematics, meant drawing up most of Tray A to figure out what dimensions I had to work with [01:33:14] https://cad.onshape.com/documents/92cad92555e98e88fa5f5e38/w/0e5bae8ff640d26b83a1661a/e/4e906f0102f1d0e0519a1adf [01:34:32] I have a fairly good idea of how I want to do the board layout now, so hopefully I'll be finishing that and sending the board out in the next few days [01:35:43] wow, that's a lot of work. looks great! [01:36:00] thanks! :) [01:37:35] https://i.imgur.com/DbfJqbp.png [01:37:41] that's where I'm at for layout [01:38:00] it's doable with four layers with routing all the signals on the outer layers, but only just [01:38:10] I'm a bit worried about crosstalk but I thiiiiiink it will probably be okay [01:40:26] Yeah I had similar issues with getting everything onto 4 layers that way but your densities are higher than mine since i stuck with 0.1 inch DIP packages. [01:41:04] I always get a kick out of the contrast in the 50 year gap in technology when I see things like this. :) [01:42:13] I used 4 layers with all signals on outer layers for my monitor connector breakout board I created for my logic analyer. I didn't encounter any noise issues. [01:43:05] hmm, that's good to hear [01:43:39] how dense was it? in order to get things to fit I have 6mil traces spaced 15 mils center-to-center (so 9mil separation between trace edges) [01:43:59] https://drive.google.com/open?id=1cuLhT6BICObnwTH4TzAGRSUjsW9CicDn [01:44:26] oh cool [01:44:27] I did 6 mil with 6 mil spacing. Zoom into the monitor connector to see. [01:44:59] nice :D [01:45:40] so the only thing that might hurt me then is distance -- since most of these signals will be travelling 5+ inches side-by-side [01:45:50] hopefully should be okay though [01:46:58] My experience was that you may find you need to go to stiffer pull-ups but I'm running my DSKY with a 5ft unshielded cable. [01:47:23] hmm [01:47:34] I need to figure out what my cap on the pullups is so I don't blow up the micrologic transistors [01:47:49] right now I have them sized to more or less match the micrologic [01:47:49] I'm running with 470 ohm pull ups which are very stout. Don't suggest you try that with the real AGC. :) [01:47:52] oh wow yes [01:48:06] yeah the real micrologics had 3.6k up to 4V; current monitor design is 3.3k up to 3.3V [01:48:18] I decided I wanted to use a sledge hammer to prevent noise issues. :D [01:48:22] hehehehe [01:49:19] Yeah 1ma may be a little sensitive to noise. But then again, look at pictures of the original break-out boxes. They had a decent amount of cable they were driving. [01:49:40] oh the original CTS was ridiculous [01:50:36] they used 10V for some of these signals [01:50:43] I think [01:50:43] hmm [01:50:54] well, NHALGA was 3V through a 510 ohm resistor [01:51:14] How much current can the RTL chips sink? [01:51:29] I figure though that whatever I do on this little 5-inch connector can't be a whole lot worse than the rest of the distance the signals have to go across the bit Tray A backplane [01:51:44] that is an excellent question, and i knew the answer at one point [01:52:03] That's only 6ma at 510ohm [01:52:06] I need to dig it up again [01:53:34] I thought they powered the pull-ups from an external supply and the AGC only needed to worry about sinking the current? [01:53:49] that's the original design, yes [01:54:16] for this design, because I'm paranoid, I'm deriving my 3.3V rail from the 4V output from the AGC [01:54:26] so it can only apply power to the computer when it's on [01:54:39] understand [01:54:57] I am going to have a jumper selection to use the FPGA's 3.3V rail power though, in case that doesn't pan out [02:01:02] hmmmmm [02:04:43] https://drive.google.com/open?id=1N_q52g5tN3Wnt9cWD5ZLzjOVOLj9T5kb [02:04:56] there's the "final" schematics for the monitor, if you want to take a look [02:06:01] very open to suggestions :) [02:07:18] I'll take a look [11:59:03] hi indy91, sorry I'm late [11:59:17] hey [11:59:20] no problem [12:00:01] thanks for the message before, it's nice to know my mission is on track [12:00:54] yeah, the maneuvers called "MCC-X" are midcourse correction [12:01:03] mostly with a nominal DV of 0 [12:01:14] so if they are too small to be burned, they don't have to be done [12:01:29] the abort maneuvers during translunar coast are called "TLI+X" [12:01:50] you will have gotten two of those in Earth orbit already [12:01:53] ahhh right, I thought MCC stood for Mission Control Centre [12:02:03] it does [12:02:18] to not get those terms confused, they often used MCC-H [12:02:24] for Mission Control Center - Houston [12:02:49] that was a NASA convention? Or a NASSP one? [12:02:57] NASA [12:03:20] right ok [12:03:33] "MCC-H" is all over the flight plan [12:04:00] ok, I'll remember that next time I see it [12:04:10] the actual flight plan, not our Checklist MFD [12:05:16] any other questions? I've read only a little bit in the chat log from the times you were here [12:05:21] Ahh I see. Where can I find the flight plans? I was going to mention that it looks like some of the checklist items differ from the AOH Vol 2 handbook you linked me to. Presumably those are differences between Apollo 11 and Apollo 16 flight plans? [12:06:07] The main thing I've been trying to work out is the x-coordinates for various components on the LM [12:06:36] the AOH basically has long form procedures [12:06:47] the flown checklists are derived from the AOH, but not identical [12:07:14] In 0g it doesn't make much difference, but acceleration in the spacecraft can vary from 0 to 4 gs, and whenever it's accelerating, the fluids in the ECS will try to fall, particularly the water and glycol [12:07:27] https://www.hq.nasa.gov/alsj/a11/a11fltpln_final_reformat.pdf [12:07:59] keep in mind that NASSP currently doesn't simulate LM systems before the LM is ejected from the S-IVB [12:08:08] at that point the LM gets created as a vessel in Orbiter [12:08:45] all the final flight plans for the Apollo missions are available online, just Apollo 7 only has the preliminary one [12:09:01] the one I linked is a nice looking reformatted one, with a few, smaller errors [12:09:09] Ahh ok awesome [12:09:44] And I suspected that was the case with the LM. My breakpoints in the LM code weren't catching during startup [12:10:00] yeah [12:10:03] it would still be nice for fluids to behave realistically in 1/6th g on the moon though [12:10:13] sure [12:10:24] before Orbiter 2016 it wouldn't have been possible to have a separate LM vessel [12:10:37] now it is possible, but we don't plan to have that any time soon [12:11:04] yes, you mentioned that was why there wasn't a separate project for the CM/SM/each saturn stage [12:11:12] yeah [12:11:17] eventually we want to have that [12:11:26] it would make many things easier and better [12:11:44] we need to fake aerodynamics and other properties for the whole stage [12:11:50] one other thing, I continued with the mission, but now I need to complete a P23, and I'm having a bit of trouble working out the required codes. How do I indicate which horizon I want to use? [12:12:02] every time there is staging there is a huuuge mesh, texture and parameters change [12:12:12] everybody has P23 issues [12:12:29] glad to know I'm not alone [12:12:41] don't think anybody has successfully navigated home just with P23 [12:12:48] we know partially why that is, but not fully [12:13:20] https://history.nasa.gov/afj/ap15fj/csmgc/3-09.gif [12:13:24] here are the codes [12:13:35] ENH for Earth Near Horizon [12:13:45] L for Lunar [12:13:47] F for Far [12:14:35] ahh awesome, thank you [12:16:10] also, my brain hurts from the alternating view we use for the split line-of-sight sextant [12:18:48] yeah, I took a look at that earlier. I'm not looking forward to having to use it. [12:19:20] you don't have to if you don't want to [12:19:31] it was just practice for the case communications are lost [12:20:09] then you need to navigate on your own [12:20:18] otherwise it's all state vector uplinks [12:20:20] no that's fine. I'm trying to learn how this thing works, so it's good to give it a try [12:20:48] does NASSP MCC adjust burn trajectories based on your actual state vector? [12:21:16] yes, based on the actual, current trajectory [12:21:48] for anything that the MCC feature is uplinking and calculating [12:22:02] that's really cool, that must have taken heaps of work to get right [12:22:12] it did, yeah, haha [12:22:17] and it still needs more work [12:22:29] you can do all the same calculations yourself with the RTCC MFD [12:22:43] if you want to play flight controller [12:23:11] a big part of it is finding original documentation on how things were calculated, which constraints apply etc. [12:23:12] haha yeah I took a brief look at that, I'll need to do a lot more reading to get my head around the RTCC [12:24:28] I just learned today about the enormous body of documentation that's only available in NARA boxes. [12:24:39] yeah, of all kinds [12:24:47] like my favourite kind, "RTCC Requirements" [12:25:05] and I believe they would even have a full set of the checklists of all Apollo missions [12:25:18] and I guess Grumman drawings [12:25:55] indeed, thewonderidiot sent me a huge list of Grumman blueprint numbers that are available it NARA. Problem is I have no idea which ones I need [12:27:35] yeah, that's not so easy to find out [12:27:47] sometimes you find a document or drawing reference another drawing by number [12:30:56] yeah. I think for the time being I'll need to estimate coordinates with what I have available. If I get more accurate data I can modify it later. The theory should still work fairly well, especially for the gasses [12:33:40] what do you need exact coordinates for? [12:38:06] well, think of a water pipe network on Earth. Most of the fluid motion is caused by gravity [12:38:48] right [12:39:05] in 0 g, that doesn't matter in a spacecraft. But whenever there's an acceleration due to gravity, water is going to tend to flow downwards, and the relative "elevation" of different parts of the network can have an effect on how the fluid flows [12:39:24] *acceleration due to gravity or thrust [12:39:56] should be easy to get an acceleration vector for the ECS [12:40:07] just the same calculation as the accelerometers do [12:40:31] I would imagine there would be a way for me to just get the value from wherever the accelerometers get it [12:40:59] yeah [12:41:47] an Orbiter API call and then some calculations [12:42:23] but the more accurately I know the actual "heights" of each component, the more accurate the flow simulation will be. Water flowing down a pipe exchanges potential for kinetic energy, and the bigger the drop, the faster it flows [12:43:00] For water, there's a good chance gravity might be the most significant driving force, even in 1/6th gravity, although I won't know for sure until I do the calculations. [12:49:50] aside from the pumps that is [12:53:25] I've certainly never researched that part of the ECS, so I won't be much of a help [12:55:34] no worries, I'm happy to go searching, and if necessary I can probably approximate most of the required values. [13:25:18] By the way, I just noticed, in the Apollo 11 flight plan, it says STAR 40 ENH, but the code it gives is for EFH. I'm pretty sure EFH is correct, since the ENH to star 40 is in shadow. [13:27:29] Page 115 of the A11 flight plan [13:30:35] ok I'm off to bed, thanks for all the help indy91 [13:37:10] .tell msligo Yeah, that's an error in the reformatted flight plan. I knew about that one. [18:07:25] morning! [19:02:35] morning! [19:02:40] hey [19:03:07] what's up? [19:03:31] IRC on phone does work [19:03:36] haha nice [19:05:43] Steve is trying uplinks, I read [19:15:03] not just trying, but has them working well now :D [19:15:32] he's able to run through the padloads now [19:15:55] so he is pretty close to being able to do more of your kind of things [19:23:49] awesome [19:25:23] didn't read all of the chatlog, last I read was some program he was getting [19:25:38] program alarm* [19:28:02] yeah, turned out his uplink pulse widths were too wide, and were generating multiple SHINCs or SHANCs per pulse [19:28:49] neither of us realized it before yesterday, but the pulses directly feed into the counter cell, so if they are wider than 1 MCT (the length of the resulting SHINC/SHANC), then it'll just do another one [19:29:09] so the pulses need to be < 11.7us at the bare minimum [19:29:17] his pulses at the time were ~90us [19:29:33] what alarm did he get? 1107? [19:29:38] 1106 [19:30:15] which I think is what you meant :P [19:30:59] indeed [19:31:51] that happened a few times during the actual missions [19:33:45] it's almost guaranteed to happen in the LM whenever the DCA or DUA were turned off [19:34:59] I thought Apollo 9, but I probably misremembered [19:35:07] maybe 7 [19:35:57] Can probably easily happen with some sort of ground equipment issue [19:40:24] Apollo 13 had one, when they moved the Updata switch [19:45:45] yeah definitely [21:07:59] night! [00:47:35] Hey Mike. I looked at your schematics and I cannot do any better. They look good. Only suggestion is to possibly build up 2 or 3 copies with different value pull up resistor packs [00:49:37] yeah, for sure -- part of why I'm using the larger resistor networks is to make replacing all of the pullups much easier [00:49:50] thanks for looking at it! [00:50:56] I have mixed feelings about drawing the power from the AGC but understand it's safer that way as long as you don't draw too much from the 4VDC supply [00:50:59] I'm almost done routing the test connector breakout traces, and once that's done it's just a matter of reassigning all of the FPGA and resistor network pins to match trace order [00:51:14] yeah for sure [00:52:08] before we actually draw the power from it, I'm going to check the duty cycle on the 4V power supply, to make sure it has enough overhead to source the additional power [00:52:25] Only alternative would be a power switch (relay) enabled by the AGC +4V to turn on power to the monitor. [00:53:05] hmm [00:53:30] would be similar to the standy relay used in the power supplies [00:53:37] standby [00:53:48] right [00:54:43] I would run the AGC 4V to the base of a transistor to energize the relay. That way you would only have the base current of the transistor being added to the AGC 4V supply [00:54:55] maybe I'll do that anyways for the FPGA-sourced option [00:54:57] Most likely not required but that's the only alternative I thought of [00:55:13] so if we set the jumper to use FPGA power it goes through the relay first [00:55:30] what worries you about pulling the power from the AGC? [00:55:40] Right, that way even FPGA power is cut when the AGC is not on [00:56:18] if 3.3k works for pullups, power draw will be ~500mW [00:56:20] Only worry it the unknown. I have no idea what margins exist. As I said, it could be just fine. Just don't know how much head room is in the current power supply [00:56:35] yeah [00:57:57] ...yeah I don't think we looked at the duty cycle on either of the supplies when we had the whole thing together [00:57:59] Just don't know what trade offs were made in the original supply design relative to power needs of the AGC. Checking the switch frequency will let you know if there's anything to be worried about like you already mentioned. [01:00:44] oh interesting [01:01:15] computer design review says that there can be an 8.5V transient on the 4V rail when the computer goes into standby [01:01:36] that's not ideal... [01:02:48] Hmnnn.... yeah interesting. That would not happen with modern designs. Guess is was okay since the computer was already held in reset when that power spike was introduce. [01:03:26] that's above the abs max on this LDO :/ [01:03:37] How fast is your 3.3 regulator???? [01:04:43] regulator says it can only take 6V absolute maximum [01:04:59] Ouch, that will leave a mark.... [01:05:14] Okay, don't go into standby? [01:05:46] unfortunately I think this might also happen when the computer turns on [01:06:04] my SPICE simulations of the supplies always showed things like that, but I assumed it was a simulation artifact [01:06:39] Use a relay and RC delay to only turn on monitor after 4VDC has been present for a specific time constant? [01:07:26] I wonder how bad of an idea it would be to put a zener on the input [01:09:05] That would most likely work. Would want to model and see what if anything the zener does to power/ground to the AGC during that spike. [01:09:06] or perhaps there's another LDO option that can tolerate that [01:09:35] yeah, I worry about how badly the AGC wants to do that 8.5V, and if that would cause an excessive amount of current to be drawn [01:10:25] Yeah, sounds like it goes wayyy out of regulation as the switcher collapses as power is removed. [01:11:15] okay, yeah, there are plenty of other LDO options [01:11:27] I'm just going to swap it out for one that can tolerate 10V or more [01:11:49] presumably the transients will be fast enough that it won't overheat from working harder for that brief time [01:11:50] Okay good. That's easiest. Just think of all the excitement you just avoided? :D [01:11:55] haha yeah [01:12:36] anyways I was looking here to see if they listed out the margins they designed in for current sourcing capability... [01:15:20] hm [01:15:39] "Also, it is not clear how this circuit can provide short-circuit limiting at 9 amps on the +4 volts and at 10 amps on the +14 volts." [01:17:01] hmmm [01:17:30] so allegedly the 4V supply can source 9 amps... but how much is nominal [01:18:11] I wish we could find the factory test plans [01:24:54] it seems like the diabolical case would be if all 5200 collector resistors were dropping the full 4V at once [01:25:31] which would be ~5.8 amps [01:25:54] and that should never be true [01:26:48] so asking for another ~100mA from the supply *should* be well within margins [01:34:49] Makes sense [18:35:40] morning! [18:57:18] Hey Mike [19:05:46] what's up? [19:09:48] trying to get my tutorial for my Shuttle FDO MFD done [19:10:24] so that people actually believe that it works [19:10:48] hehehehe [19:25:06] hey Suzuran [20:31:11] he is trying to talk, but overwhelmed from all the NASSP progress in the last month [20:50:07] hahaha [21:09:58] night! [00:25:20] Hello everyone. For accurately modelling pipe flow in the ECS system, I need the ability to perform matrix algebra on potentially large matrices. I know that Orbiter has built in functionality for 3 dimensional vectors, but does Orbiter (or NASSP) have any sort of in-built functionality for more general linear algebra? The matrices will be large but sparse, so the ability to efficiently handle sparse matrices would also be extremely us [00:26:46] I've been looking at Eigen (http://eigen.tuxfamily.org/) which looks perfect, but if there's already a solution in Orbiter/NASSP then it's probably best not to bring in a whole new external package. [00:28:25] hey msligo [00:28:43] hey thewonderidiot [00:29:13] I can't help; you might need to ask indy91 about that [00:30:32] ok sure thing, I'll ask again when he's online [07:22:11] msligo, Orbiter API only has provisions for 3 and 4 dimensional matrizes. And they recently found a big bug in a MATRIX4 operation, so I wouldn't count on it [07:24:05] hmm ok. Would it be a problem for me to bring the Eigen library into the NASSP source code (or at least the parts that I need?) There shouldn't be any licensing issues, they say it's free to use for any software, commercial or not. [07:24:40] I would imagine that the ability to do matrix arithmetic would probably come in handy in other areas as well. [07:26:36] NASSP is GPL2 licensed, Eigen is MPL2 licensed and it looks like they are compatible [07:27:55] would that be for the actual ECS simulation? Don't forget that it has to run 60 times a second [07:28:14] so CPUs need to be able to handle that :P [07:30:01] haha of course. I've looked around, and it seems as though Eigen is one of the faster solvers available. Also, if you provide a good initial guess for the flow rates in the pipes, then the matrix solvers will usually converge in 1 or 2 iterations. Using the previous solution as the initial estimate will probably work well most of the time. [07:31:16] Also, the matrices are all fairly sparse (most of the entries are 0s) so there are further efficiency gains that can be attained if you use the right algorithms, and it looks like Eigen has functions specifically for sparse matrices. [07:31:39] sounds reasonable [07:32:20] That being said, I won't know it's performance until I actually build the thing and test it. Once I have something that works, we'll have a better idea of how long it takes to run. [07:32:47] And then if necessary, I might be able to tweak it to make it faster. [07:34:46] and who are we to make demands on performance if we still use the terribly performing bitmap based 2D panels? :D [07:36:02] haha well, you built that first, so I can't very well ask you to change it to accomodate a bloated ECS system! [07:45:22] ok, have to go, cya! [18:05:22] morning! [18:47:32] hey Mike [18:58:08] hey [18:58:10] what's up? [19:08:52] finishing the Shuttle FDO MFD tutorial [21:13:37] night! [08:43:39] hey indy91 [08:43:45] hey Mike [08:44:26] I went to an interesting talk tonight, given by one of the RTCC programmers [08:44:30] ! [08:44:39] and up until this afternoon I forgot about it, so I forgot to ask you if you had questions for him [08:44:47] but I can probably get his contact info if you do [08:44:48] haha [08:44:57] hmm [08:45:10] sounds interesting [08:45:27] from IBM or MSC? IBM I guess [08:45:31] IBM [08:45:57] what did he talk about? [08:46:14] he was writing software for 8 through 13 [08:46:16] uhh [08:46:31] it was more of a general thing, he didn't go into RTCC specifics really [08:46:52] his talk was "why and how apollo went to the moon", given to the local astronomical club [08:46:57] ah [08:47:04] so, not meant for people who knew a lot about apollo [08:48:05] right [08:48:16] well I guess I could come up with some questions [08:48:25] that I would have [08:48:44] first, why is so much of the IBM RTCC documentation HANDWRITTEN [08:49:25] then I'd like to free his basement of any RTCC documents [08:49:26] hahahaha [08:49:39] and lastly if he has any Fortran code from the time, thank you very much [08:50:11] I did ask him if he knew of any program listings [08:50:35] he did think that it was microfilmed at the time, so it may be somewhere in the NARA collection [08:50:51] ah [08:50:56] I guess that makes sense [08:51:52] speaking of... [08:52:10] I did figure out tonight that NARA has a bunch of boxes filled with IBM numbers [08:52:32] I'm having a very hard time pinning down the numbering system since we have so little info [08:52:47] and have yet to positively ID anything in the ranges they have [08:52:58] but it is definitely IBM, and so could possibly contain LVDC stuff [08:54:12] true [08:54:27] at this point we should probably just assume that NARA has everything [08:54:51] I don't suppose any of your RTCC docs have anything that look like a drawing number? [08:55:43] let's see [08:56:31] btw, what's the name of that RTCC programmer? [08:56:55] I have a contract numbe [08:56:56] number [08:57:02] Gordon Myers [08:57:06] NAS 9-996, but that probably doesn't help [08:57:13] yeah, doesn't help [08:58:17] I found a "J. Myers" in the RTCC documents [08:58:42] very prolific [08:59:13] hmmm [08:59:39] https://www.linkedin.com/in/gordon-myers-a318b113 [08:59:41] that's the guy [09:00:23] could be him, but I'm not seeing where the J would come from [09:00:33] "Project Manager for Space Shuttle Flight Software" [09:01:02] but he definitely worked on RTCC stuff in the right timeframe [09:01:39] he said he was on shuttle full time by apollo 15 [09:02:01] I guess I don't really have any specific questions. That NARA might have some RTCC code is already helping [09:02:20] if he has lots of documentation in his personal collection, that would be nice [09:02:41] any question I would have would be too specific after 50 years [09:04:00] he's still super sharp, for what it's worth [09:06:23] also, grrrr [09:06:44] from what I am scraping together, it almost looks like with IBM, things have two drawing numbers -- an IBM one and a NASA one [09:06:58] unlike MIT where their part numbers generally were the NASA numbers [09:07:34] so twice the fun [09:07:46] and the NARA boxes are all the NASA numbers, but IBM docs almost exclusively use IBM numbers [09:14:12] anyways, bed time for me [09:14:13] goodnight! [09:15:12] cya! [12:37:42] hi indy91. I've gotten a bit further, up to the "Obtain PTC Angles" step. Where do I obtain those angles from? Are they supposed to come from MCC? [12:39:04] hey [12:39:05] hmm [12:39:25] that's from the Checklist MFD? [12:39:31] what GET [12:40:07] 8:07. I took a while getting the P23 right [12:41:18] might be a generic phrase that doesn't really apply to Apollo 11 [12:41:25] stick to the flight plan [12:41:48] ok, so the PTC angles should be in the flight plan? [12:41:49] initial PTC angles, using the PTC REFSMMAT, are: 90° pitch, 0° yaw, current roll [12:42:17] might be something that survived in the Checklist MFD from Apollo 8, where they didn't use a PTC REFSMMAT [12:42:33] flight plan page 3-8 [12:43:08] ahh ok, so I'm already aligned to PY 90,00 [12:43:25] but I did notice that that doesn't put me square on to the sun. It's at a bit of an angle [12:43:30] is that expected? [12:43:34] if you did a P52 option 1 after the PTC REFSMMAT uplink [12:44:35] I did, but when I had the choice between Coarse align and Torque, I chose Coarse align. Was that wrong? [12:44:49] no, it's just different ways to get to the same target [12:45:08] coarse align is more quickly, but then it doesn't measure any attitude changes during the alignment [12:45:13] while the NO ATT light is on [12:45:27] pulse torquing is slow, but keeps the IMU measuring attitude changes [12:45:53] let's see [12:45:56] I think [12:46:07] ahh right ok. Well, I did do the P52, and the error was small (00002). So is it strange that I'm not square on to the sun? [12:46:12] Apollo 11 still used a communications optimized PTC REFSMMAT [12:46:31] I hardcoded it in the MCC code, so it's not the usual calculation method [12:46:37] so it might be ok to be a bit off [12:47:13] hmm, I can confirm that the HGA is pointing directly away from the Earth right now [12:48:33] and the sun is at an angle of about 60 degrees, with 0 degrees being edge on to the stack [12:50:57] ohhh no [12:51:01] I know what it is [12:51:10] I set it to Roll 90 instead of Pitch 90 [12:51:21] Noun 20 is Roll, Pitch, Yaw [12:51:24] :| [12:51:51] yep, give me a sec I'll try and fix it [12:52:08] you are not winning the CMP competition then for whoever is using up the least RCS :D [12:53:12] hahaha no, I am definitely not [12:53:25] you will have fun with that in the LM, IMU angles and FDAI angles are not the same there [12:53:36] Roll and Yaw are different between those [12:54:08] I am definitely not getting CMP of the year. Earlier in this sim, I successfully soft docked with the LM, then accidentally undocked instead of hard docking [12:54:35] I'm keeping that in mind, since I feel like I only get a limited number of dockings (nitrogen cartridges or something) [12:54:50] I may return from the Lunar surface and be unable to dock! [12:55:24] yeah, I think you can only do 4 hard dockings [12:55:42] just need to do a small EVA from the LM to the CSM then [12:56:24] haha yep, "small" [12:56:32] although wait, did you say hard dockings? [12:56:47] I only soft docked before releasing. Maybe I didn't use up one of my dockings? [12:56:52] hmm [12:56:56] I'm no expert [12:57:43] but yes [12:57:58] docking probe retraction [12:58:45] you can do that 4 times [12:58:47] ok, maybe I'm fine then. Does it apply to undocking too? Unless I'm mistaken, I only need to dock with the LM twice in the whole mission. [12:59:13] no, probe extension is "free" [12:59:36] ahh, well it looks like I might have been saved by NASA redundancy [13:00:51] yeah [13:01:05] otherwise it's an EVA for you after the rendezvous [13:01:15] obviously a scenario they planned for [13:01:21] there are procedures [13:01:47] LM Contingency Checklist [13:02:48] ahh awesome. Well I'll keep going with this sim for science, and report back on my results [13:03:48] sure [13:04:04] doing the LM activation and landing is always fun [13:04:09] have you tried that yet in any way? [13:05:04] I guess you are a few simulated says away from that [13:05:08] days* [13:11:27] nope, not yet [13:11:47] I haven't done much in the LM except for activation in Apollo 9 [13:32:47] ok, got to go. Thanks for all the help. [20:18:00] morning! [20:29:58] hey [20:30:17] making a bit more progress with IBM drawing numbers [20:30:45] drawing 7910139 is "S-IU-503 Instrument Unit Electrical Schematics" [20:31:04] and NARA has a box ending with drawing 7910146 [20:31:35] pretty close [20:31:53] it's super likely they have it, so I might request it [20:32:44] wow [20:32:52] that's not even your area of specialty :D [20:33:05] but I could probably do a thing or two with IU schematics [20:33:32] I'm getting a NASA number of 50M35010 for the LVDC, which I can't place in a box... they have many 40M numbers, but not 50M [20:34:13] all thrown in a big fire after ASTP [20:35:17] specifically all the 50M cards? :P [20:35:29] of course [20:36:19] did you use the "IU System Description and Component Data" document to figure out the numbers? [20:36:45] yeah [20:37:09] pretty good for part numbers [20:37:26] there's another one that's better, one sec [20:37:45] oh no, that is the good one [20:38:09] https://www.ibiblio.org/apollo/Documents/MSFC-III-5-509-1-Saturn1BVInstrumentationSystemDescriptionTechnicalManual.pdf [20:38:16] that's where 7910139 came from [20:39:09] ah right, that one [20:40:08] also have been trying and failing to get a drawing number for the software [20:40:53] would it even have anything like a drawing number? [20:41:54] the AGC and AGS programs did [20:43:36] ah, good to know [20:44:46] I'm kind of tempted to just request a few random cards from boxes I believe to be IBM [20:44:57] just to get a sense for what is and isn't [20:46:08] that would make a fun puzzle [20:46:20] and an expensive one, sadly, haha [20:46:33] yep [20:46:35] Ron needs to get that volunteership :P [20:47:30] and spent the rest of his days doing scanning [20:48:59] the tantalizing thing is that I think there is a very real possibility that 40Mxxxxxx includes the flight programs [20:49:17] yeah [20:49:58] would be fun to find that before the 50th anniversary. That's a proper distraction from getting NASSP 8 done. [20:50:03] the ICDs for them were 40M336xx [20:50:55] NARA has mostly 40M6, 40M7, and 40M8 [20:51:10] and I haven't found any documents that show part numbers that start with those yet [20:51:33] EDD has contract and specification numbers [20:52:26] what do the specification numbers look like? [20:53:08] very simple [20:53:12] LVDC S p e c i f i c a t i o n No. 6150001 [20:53:20] ah yeah, that's an IBM number [20:53:25] LVDA S p e c i f i c a t i o n No. 6150000 [20:53:29] no help for these nasa numbers [20:53:33] yep [20:53:58] NTRS is doing maintenance [20:54:23] actually I wanted to try and access some restricted documents during that time, just in case they appear by accident :D [20:54:26] so desperate... [20:55:07] hahahaha [20:55:27] there was the document that transcribed pieces of LVDC code to another language [20:55:44] that one referenced the LVDC listing, but I only have the appendices saved [20:57:20] http://www.ibiblio.org/apollo/Documents/19720014529.pdf [20:57:24] http://www.ibiblio.org/apollo/Documents/19720014530.pdf [20:57:55] of course [20:58:52] just the EDD it seems [20:59:01] but they must have had a listing for this [21:00:02] they did [21:00:10] annoyingly they don't list it in the references as far as I can see [21:00:17] yeah [21:00:21] "An actual Saturn flight program listing was used to reflect detailed [21:00:22] implementation of the Saturn kernels." [21:00:31] >:( [21:00:46] the later architecture of the LVDC software [21:00:56] they completely rewrote it at one point to make it more modular [21:04:54] oh that's fun [21:05:01] I was wrong about the 1Bxxxx boxes being from IBM [21:05:12] https://history.nasa.gov/afj/ap10fj/pdf/19700026422_saturn-s-ivb-505n-flight-evaluation-report.pdf [21:05:25] that has a reproduction of drawing 1B42739 from Douglas [21:05:42] ah [21:05:45] it's a propulsion system schematic [21:05:46] hmm [21:05:56] we have partial EDS schematics [21:06:08] let's see if those have any numbers [21:06:45] no [21:07:51] damn [21:08:36] ever seen the "Inter-Center Interface Control Document Log"? [21:08:56] no? [21:09:39] that has document numbers as well [21:10:20] https://cdm16608.contentdm.oclc.org/digital/collection/p16608coll1/id/9071/rec/3 [21:10:43] download link for the whole thing: https://cdm16608.contentdm.oclc.org/digital/api/collection/p16608coll1/id/9343/download [21:11:28] just interface system stuff of course [21:11:33] I think [21:12:04] oh nice [21:12:08] this could be super useful [21:14:02] from the UAH digital collection that reappared a while ago [21:14:17] that's where the Saturn IB EDD came from, but it's not online again [21:15:32] lots of 40M numbers in here [21:15:43] all 40M3 or 40M0 [21:15:48] still no 40M6 or 40M7 [21:20:09] oh!! got a hit [21:22:01] ...aw [21:22:23] 40M68374 -- ATM ESE LC-39 Advanced Electrical System Schematic [21:22:38] 40M70829 - Power Interconnection Diagram ATM ESE [21:22:44] this may all be ATM stuff [21:23:52] or all ESE [21:24:27] yeah [21:24:43] the 719 stuff definitely isn't though, that's proper IU schematics for sure [21:26:18] you said the 503 IU, right? [21:26:33] actually they named it like the Saturn stage [21:26:37] e.g. S-IVB-503 [21:26:40] and S-IU-503 [21:27:17] in a lot of ways it is a stage in its own right, haha [21:28:07] that is one that is very likely there, yeah [21:28:35] I'm going to request it next time I order scans of a drawing, just in case it leads to different numbers for things [21:28:59] I mean, it might lead to LVDC drawings [21:29:02] but at this point I've defeated my initial excitement and am not expecting to find the really good stuff there [21:29:05] might, yeah [21:29:26] if it just gives the 50M35010 number again we'll be stuck [21:30:20] not a puzzle then, a labyrinth with dead ends [21:31:20] I'll also request 50M35010 just in case, even though I don't see a box that it would be in [21:31:38] we really do need Ron to just scan the whole lot :P [21:31:58] how do we sell it to him [21:32:16] "hey Ron, you like computers that have flown on Apollo missions, right?" [21:33:52] well, he was asking earlier about other boxes that would be good to scan, and he drove all the way to huntsville with uncertain information that LVDC software may have been there [21:33:53] it's not a hard sell [21:34:09] right [21:34:24] just that one time where he wanted to get AGC schematics done [21:34:43] oh, I'm going to insist that he not do this until we have everything from MIT [21:34:49] but this would be a good next thing to do after that [21:35:23] I definitely like IU schematics [21:35:37] we could do many improvements with those pretty easily [21:36:36] okay, let's make a deal [21:37:00] I'll get some IU schematics, and you get the later systems handbook from Lauren in case it has more detailed info :D [21:37:19] deal [21:37:26] it's time for my monthly order anyway [21:37:48] hehehe [21:37:54] last one probably was in January, so I am due for a larger document [21:38:23] perfect [21:38:52] and with that [21:38:54] good night" [21:38:55] ! [21:39:19] night! [14:49:07] hey [14:53:17] hey Alex [15:24:49] made a bit of a breakthrough for NPC burns that take non-spherical gravity into account [15:25:09] works much better now, would be important for e.g. Skylab launch window targeting [15:25:25] and Mike and I are trying to figure out if NARA has any useful IBM stuff [15:25:33] for e.g. RTCC and LVDC [15:26:34] actually, the good old RTCC documents I found on NTRS have been a big help with my Shuttle FDO MFD. You always find some obscure new page with something useful. [15:43:13] cool stuff [15:46:03] testing that right now by flying STS-82, one of the Hubble servicing mission. Mostly that mission because it has a short coelliptic phase. [15:46:42] https://media.springernature.com/original/springer-static/image/chp%3A10.1007%2F978-1-4614-0983-0_12/MediaObjects/978-1-4614-0983-0_12_Fig23_HTML.jpg [15:46:50] that's the profile [15:48:21] interesting profile [15:48:37] on my end ive been playing DCS World a lot lately on my free time, starting with the FC3 F-15C. It has simplified avionics but a flight model on the same level as all the stand-alone aircraft modules. (very good) The simplified avionics also makes it a lot easier to learn the basics. [15:49:12] yes, I liked that about flying the Su-25T in DCS [15:49:35] no overly complicated computer interaction [15:49:41] yeah [15:49:42] just, wrecking tanks [15:49:48] yep :D [15:50:33] but once I learn the basics with it, Ill move on to the F-18, and the F-14 which comes out on the 13th :) [15:51:57] so all the Fs [15:52:21] I still have to master the MiG-21bis, when I get back into DCS I'll fly that one [15:53:23] wasn't there an Eurofighter in development for DCS? I'd like to get one of the jets I saw in action [15:53:33] so basically Phantom, Tornado or Eurofighter [15:53:43] well I have the M-2000 [15:55:35] not interested, haha [15:55:53] and not a eurofihgter of course as Ive just noticed [15:56:24] I must say im not very knowledgeable about European fighters [15:56:37] Eurofighter might be a bit too recent to be properly simulated [15:56:41] too secret [15:57:10] right [15:57:15] I worked at the German equivalent of Edwards AFB for half a year, most of my knowledge is derived from that, haha [15:57:44] I see [15:57:52] the AV-8B is lots of fun [15:57:54] with a runway long enough so that it could be an emergency landing site for the Space Shuttle [15:58:09] I should try that with SSU some time [15:59:46] yeah, I never tried a simulated VTOL aircraft [15:59:52] should be quite fun [16:00:36] very fun in VR [16:01:33] its more stable then say helicopters, which sometimes make me feel queasy in VR [16:02:03] I guess my experience flying the LM helps :D [16:02:20] haha, the other way around than usual [16:02:31] haha yeah [16:03:03] wouldn't be a very useful requirement for a new helicopter pilot [16:03:44] oh damn [16:03:54] is David Scott really the last one who landed a craft on the Moon [16:04:36] one CDR and three LMPs alive [16:04:56] yeah helos have a whole bunch of more control complexities then just a down pointing thrust [16:05:22] my very limited experience with that is from FSX helicopter missions [16:06:27] actually [16:06:46] I've flown a gyrocopter simulator, like a full flight simulator with everything [16:07:20] helps when there is a company producing those simulators just down the road from your university :D [16:10:42] nice [16:14:53] have you ever flown a real helicopter? [16:24:04] nope never, too expensive! [16:24:40] But Id like to try an R44 or something one day [18:56:09] morning! [19:05:14] hey Mike [19:12:45] what's up? [19:14:12] I think I figured out the whole "phantom plane" business for rendezvous plane change maneuvers. Properly this time. [19:14:50] doesn't help that the annoying non-spherical gravity is making the orbital plane wobble around [19:15:15] haha nice [19:15:24] but it iterates more stable now [19:15:33] and I can set the tolerance to much lower [19:16:20] connect that to an ascent simulation and you could make a launch window targeting tool with this [19:17:07] awesome [19:18:10] flying one of the more interesting Shuttle rendezvous profiles to test this [19:27:01] systems handbook request has been sent [19:32:04] great [19:32:19] I'll see if I have anything else to lump into this request from the AGC side and send it tonight [20:39:02] heh [20:39:13] was trying and failing to find AEA drawing numbers [20:39:40] and I just noticed that there are 6 boxes of cards that are just categorized as "GAC Vendors" [20:39:43] who knows what numbers are in there [20:41:51] GAC Vendors? [20:42:50] I assume they mean Grumman vendors [20:43:07] one of the boxes also has some Grumman drawings in it [20:44:09] ah of course, GAC is Grumman [20:44:28] seems like if there are AEA drawings they are probably in those boxes [20:44:53] yeah, sounds likely [20:44:56] hmm [20:44:57] well [20:45:04] Grumman didn't build the AEA [20:45:31] right, but TRW made it for them [20:45:35] yeah [20:45:42] to specification LSC 300-330-10 [20:45:58] TRW's part number was 220000 [20:46:14] and the AEA documentation is even worse about giving drawing numbers than the LVDC [20:46:44] ...what else did TRW make for Apollo? [20:47:49] simulation software [20:47:59] I have lots of joint TRW and MSC memos [20:48:28] also apparently the DPS? [20:51:00] yeah [20:51:26] Apollo Reference Mission Program [20:51:32] we have the 400 pages user manual... [20:52:38] the user manual for what? [20:53:00] Apollo Reference Mission Program [20:53:32] that's the probably enormous simulation software to simulate full lunar landing missions [20:53:34] made by TRW [20:53:54] and there are lots of reference trajectory documents by TRW, "preparated for NASA" [20:53:57] yeah [20:54:09] ah, lol, this manual has Apollo landmark coordinates [20:54:10] I'm looking for hardware though, to try to sort out how their drawing numbering system worked [20:54:28] didn't have to chase after the Apollo 8 CSM Earth Landmark document after all... [20:55:48] yeah, unfortunately every single document in my TRW folder is simulation related [20:57:30] hmmm [20:57:36] found a listing of LMDE part numbers [20:57:49] and no DPS was so off-nominal that they included drawings in the DPS evaluation reports [20:58:00] https://apps.dtic.mil/dtic/tr/fulltext/u2/822318.pdf [20:58:03] pdf page 85 [20:58:41] nothing really matches NARA boxes... [20:58:54] and also nothing matches AEA numbers [20:58:57] damnit TRW [21:11:54] yeah, I'm not finding anything useful TRW related [21:19:34] night! [18:07:27] Guenter! [18:07:34] I guess it was me :P [18:07:36] good morning! [18:14:41] hey Mike [18:17:08] what's up? [18:18:11] ooooo [18:18:38] Lauren is unsurprisingly faster than the national archives :P [18:19:01] yes [18:19:16] anything really good in here? [18:19:24] the document is about the same we already had, with the expected changes to e.g. the LVDC timebase definitions [18:19:29] and a complete EDS section [18:19:36] which was missing from the AS-503 one I believe [18:19:39] so that is really useful [18:19:41] yeah it was [18:20:56] and certain spacecraft/IU interaction things were a bit unclear, which this document should help with [18:23:35] so yeah, pretty good to have this [18:23:49] probably not for drawing numbers though [18:24:29] yeah, no real new leads there [18:24:42] they even stripped out the one 40M number that the AS-503 handbook had :P [18:25:25] haha [18:25:46] well, the LM-1 Systems Handbook had some details that are missing from the LM-8 one, so, they are consistent :D [18:26:50] hehe true [18:26:59] well hopefully 7910139 pans out [18:27:08] and if not, 7910138 or 7910137 [18:34:33] yeah, would be great if we could find something this way [18:52:30] yeah, Ron never had the E.194T boxes I believe [18:55:08] I guess they will gradually become more Shuttle related [18:55:20] but there will surely be some late Apollo, Skylab and ASTP stuff [18:55:29] almost certainly, yeah [18:55:59] there is a 1976 memo for the Shuttle I'd like to get, guess that's not in that record group, haha [18:56:13] and I might already have that memo, just in a different form [18:56:36] heh, what do you mean? [18:57:07] well, the same content as the memo, not the memo itself [18:57:44] ah, gotcha [19:07:25] damn! [19:07:32] nothing found for 7910139 [19:07:42] which is AS-503 [19:08:06] I'll have her also check 7910137 and 7910138, which are AS-501 and AS-502 respectively [19:13:02] hmm, unfortunate [19:25:03] yeeaaah [19:25:06] not really surprising I guess [19:25:23] it could be that these 791xxxx drawings are also ATM or ESE [19:26:01] also unsurprisingly she couldn't find 50M35010 for the LVDC [19:26:17] but she did have the AGC drawing I wanted so that's a plus [19:27:14] 2003076, the rope jumper modules... which we'll need to recreate when we dump smaller sets of rope modules [19:59:37] AGC versions that didn't need all of the memory yet? [20:00:38] yeah, like Retread 50 in the computer history museum's AGC [20:00:42] if we dump that we'll need 4 jumpers [20:01:43] well, technically we wouldn't need any, but without them we run the risk of stressing the rope driver circuits a bit, and possibly damaging them [20:01:58] when it tries to access memory that isn't there [20:02:44] I think even without, because it will be wanting to run inhibit pulses through all of them [20:02:56] ah, right [20:03:00] but that is a good point, and something I need to research [20:03:42] oh no [20:03:44] no research needed [20:04:01] https://ia902805.us.archive.org/BookReader/BookReaderImages.php?zip=/12/items/agc_handbook_jp2/agc_handbook_jp2_jp2.zip&file=agc_handbook_jp2_jp2/agc_handbook_jp2_0506.jp2&scale=4&rotate=0 [20:04:11] scary handwritten note [20:04:33] "needs jumpers in unused locations to avoid degradation or failure of rope driver stages" [20:05:21] yep, pretty clear [20:06:09] it's scary how many things like this are just one-off mentions or handwritten notes in documents we've found [20:06:15] like without that note we'd be totally oblivious [20:06:29] every relevant person would know that back then [20:06:45] and just a few days ago I stumbled across a passing mention that the 4V rail in the AGC can spike up to 8.5V when entering standby, and this was totally normal and expected [20:07:04] that's quite the spike [20:07:09] except it would have completely blown up parts I had selected for the monitor board, so I've had to replace them with more tolerant versions [20:07:49] better than blowing up the AGC [20:08:09] well, this part blowing up could have been harmful to the AGC too, so it's a good thing I found it [20:09:12] yeah [20:09:28] I just hope there's nothing else like this lurking [16:49:02] morning! [18:14:57] hey [18:17:56] yo [18:18:01] what's up? [18:19:12] Not much [18:53:49] and you? [18:57:22] just work [18:57:29] and putting together tonight's NARA request [18:57:59] which I think will be two more AGC drawings and the two IU drawings [18:58:16] really hoping they have 2003879 [18:58:52] I think that's the only hope for figuring out what the impedance they selected for the jumper modules was [19:07:28] better than having to make an educated guess [17:09:19] morning! [17:42:40] hey [17:46:24] what's up? [17:48:39] badly implementing new SSU features so that I can use them just for myself [17:48:52] hahahaha [17:49:07] maybe I'll show them a code snippet or two, so that they see how it's done [17:50:21] in most cases it is "the AGC could already do this, I know how that works" [17:50:40] right [17:50:44] how active is SSU development? [17:52:32] pretty active, but they often seem to get lost in details [17:52:54] and missing some big stuff [17:53:01] or at least not the details I care about [17:53:16] or at least missing the* [17:54:49] like, they don't really have provisions for what we would call a padload [17:55:05] I think they postponed that to a time when they have a better Shuttle computer simulation?! [17:55:26] but that makes a bunch of things rather inconvenient [18:08:37] hehehe [18:08:43] I see [19:06:23] no word yet from NARA about 7910137 or 7910138 [19:06:51] I'm a little afraid that maybe I should not have requested both, just in case they actually have both [19:08:37] because it takes longer? [19:43:55] haha well [19:43:58] that is a minor thing [19:44:20] the real problem is that if they have both, and both have many pages, it might get unexpectedly expensive [19:46:03] ah, of course [19:46:21] $4 per image adds up quite quickly [19:49:25] yeah [19:52:36] also if you didn't see it, there's a new AGC video up :D [20:27:15] I saw it [20:27:36] you basically told me all the same things, I think, but it was a good watch anyway [20:28:29] :) [20:28:45] also :( I think it is too late now to get NARA drawings today [20:29:10] I really really want to know if they have 2003879... and also really want to know if they have the IU schematics [20:32:27] that would be interesting to know [20:52:39] night!