[16:43:56] NASSP Logging has been started by indy91 [16:43:58] hey [16:46:04] morning! [16:46:54] what's up? [16:50:42] looks great, thanks a lot! [16:51:09] the first one there I deleted over a hundred blank pages from haha [16:51:10] so many [16:53:56] ah, probably a lot between the MED format tables [16:53:59] but also all over [16:54:08] yup [16:54:51] I'll keep the originals of course, but these new ones are a lot better for "every day use" [16:55:39] yeah for sure [16:55:46] I keep all of my raw scans too, just in case :D [17:02:54] sometimes OCR goes wrong [17:02:59] like in the LVDC EDD [17:03:05] half the time it OCRed it [17:03:11] l i k e t h i s [17:03:19] not great for searching haha [17:03:50] but I don't need that fixed or anything, I know where everything is [17:06:42] yeah OCR is still not great haha [17:07:10] definitely an area with lots of room for improvement [20:36:50] hmm [20:37:22] when it says under "other programs used" that a function A uses function B [20:37:32] but in the program flow it says it uses function C [20:37:41] then I am allowed to choose between B and C, right? :D [21:28:58] hahaha yeah I think so :D [21:31:48] might point to an interesting development history. When the RTCC first got this function it was probably tested as its separate thing before and it brought some subroutines with it that made it work independent from other RTCC functions and constants. [21:32:16] but it would be a lot easier and more efficient to make use of those functions and constants, so maybe they later decided to change it. [21:32:27] and fixed it on the first page of the program writeup [21:32:30] but not in the flowchart [21:32:50] although that (presumably) older subroutine hadn't been deleted by April 1969 [21:32:59] don't think anything else would use it [21:33:10] so I can't really be certain [21:35:55] this was actually in one of the documents you OCRed... although that didn't really play a role in me looking at it :D [21:45:00] hwy guys [21:45:05] *hey [21:45:20] it'll be nice to search those now [21:45:24] hey Matt [21:46:01] the function I was talking about was actually ALAIES, PIAIES in the RTCC [21:46:28] ahh [21:46:29] I think they stopped using it because the RTCC had a simpler way of calculating the longitude [21:47:42] but when it got ported to the RTCC they at first took the function with it [21:49:37] always interesting to trace these things. There are also some functions for the moon-centered RTE which are directly coming from a 1966 TRW memo I have [21:50:24] ... that one has also Fortran code if you needed any more :D [21:50:49] oooooo :) [21:51:06] speeking of code [21:51:16] not fortran though [21:51:45] have you ever looked through the gsfc tape that is up on cbtapes? [21:52:41] don't think I have [21:53:41] oh this TRW memo has one routine that is in assembly [21:53:46] IBMAP [21:53:59] I think it's just os360 addons, and all in 360 assembly, but might interesting [21:54:04] Macro Assembly Program? [21:54:33] I'm working on vim syntax highlighting for IBMAP [21:54:52] do you have a link for the gsfc tape? [21:55:25] https://web.archive.org/web/20100525064117/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730064342_1973064342.pdf [21:55:28] the TRW memo [21:55:45] https://media.discordapp.net/attachments/735589860131340368/904033873325850634/unknown.png [21:57:26] https://www.cbttape.org/histmods.htm [22:01:26] hmm, can't say from the table of contents that it obvious to me what the tape contains [22:08:02] ah look at that [22:08:26] ALEFEM from the MSC memo and subroutine JPLEPH from the TRW memo are basically identical [22:09:32] I guess they read the same kind of ephemeris tape [22:11:22] good night! [23:56:58] Thank you! I grabbed them both [14:25:53] good morning [14:31:21] hey [14:50:54] the RTCC used interpolated libration matrices for the Moon [14:51:08] I still have to convince myself that interpolated rotation matrices are still good rotation matrices :D [14:56:54] but I could easily generate the numbers for the tape with the Moon position/velocity/libration data for ALEFEM [14:57:02] basically already have to do the same for our RTCC [15:09:50] oh nice. [15:12:48] I wonder if we could use the same format to load our rtcc [15:14:01] probably [15:14:09] would be a very large txt file [15:14:47] because it apparently supports epochs from 1951 to 1999 [15:16:05] right now it calculates the stuff from Orbiter API calls [15:16:10] when the scenario is loaded [15:16:21] or in non-MCC scenarios when you open the RTCC MFD for the first time [15:18:55] oh [15:19:01] the TRW memo describes the tape format [15:19:11] last few pages of it [15:20:47] although there is one difference I am seeing to the format in the RTCC and in ALEFEM [15:21:02] solar position vectors at 96 hour intervals and not 12 hours as in the RTCC [15:21:31] so might not be the same format then [15:24:49] if it isnt, it's probably very close. [15:25:47] yeah, probably just denser numbers [15:26:08] and it's 12 hours for the lunar data already [15:35:00] interesting that the tape starts for 1951 [15:35:24] there is probably a separate tape covering the more commonly used B1950 coordinate system [15:35:41] and that then has data not just near 1950 but until 1999, too [15:35:55] that's the coordinate system they used from Skylab to the Space Shuttle [15:36:00] including the Shuttle [15:45:13] good morning [15:46:38] hey Ryan [15:53:17] morning! [15:54:33] indy91, Wedge's fwd hatch valve is open :P [15:54:54] o2 flow high explanation [15:54:58] hey Mike [15:55:04] that will cause some O2 flow, yes :D [15:55:16] at least the emergency regs are maintaining pressure [15:56:17] I thought why is Mike so early, but we are in that weird week where the US still has daylight saving time, but we don't [16:02:25] yep [16:02:54] Oh interesting [16:03:07] the few weeks of the year I drive to work in the dark [16:04:41] timezones and DST are such a mess haha [16:05:41] If it were up to me I'd get rid of FST entirely. It no longer serves a practical purpose and my biological clock never likes adjusting to summertime. [16:05:45] s/FST/DST [16:07:57] yes [16:15:20] we should all just use UTC. [16:15:46] have one time is nice [16:16:40] everything inside Google runs on "GST" (Google Standard Time, aka Pacific Time because of their CA headquarters), regardless of where in the world it is :P [16:16:42] It's always fun to go on the timezone people mailing list and watch the discussions of "oh crap this government is changing the timezones tomorrow and didn't tell us" https://mm.icann.org/pipermail/tz/2021-October/030967.html [16:18:04] If everyone were to use UTC, you would still have a list of what time is "morning" where you are. [16:18:06] bad ide [16:18:07] a [16:18:12] China tried it once I think [16:18:42] https://www.theatlantic.com/china/archive/2013/11/china-only-has-one-time-zone-and-thats-a-problem/281136/ [16:19:51] or we just go back to the time when church clocks were adjusted to actual local noon :D [16:28:02] next time I make an excel graph for some work thing, I'm going to make the time scale I "seconds since local solar noon" [16:28:15] *in [16:34:36] just get a sextant and you are good to go [16:36:42] indy91, one of the references in that TRW memo is "Apollo Trajectory Design Program" TRW No. 3832-H001-TU000. I don't suppose we know where that is? [16:37:42] don't think we have anything about that [16:38:36] every contractor had a program like that it seems [16:43:14] I only know about the Apollo Reference Mission Program from TRW [16:56:19] aparently the author listed for that reference passed away over 10 years ago, so that's a dead end [17:06:36] ouch. that was an accidental and somewhat insensitive pun.... [17:09:32] hah [17:17:54] I've been making super good progress with the rope reader. I think I have all of the circuits basically defined outside of its power supply. FPGA boards for it are arriving today :D [17:23:46] nice! [17:31:21] how hard is fpga programming? I have zero experience. I'm interested in learning. [17:31:45] it's not hard, just different [17:32:48] you just need to keep in mind that you're designing hardware, not software, so you need to let go of your software conceptions as much as you can haha [17:33:06] think about things in terms of logic gates and what you want to happen on different clock edges and whatnot [18:13:20] have we offered an FPGA with the AGC sim to Israel and India yet? Maybe that improves their moon landings [18:14:00] hahaha [18:24:16] did some nice coordinate system related improvements today [18:24:33] the epoch is now specified as a year, instead of a lengthy MJD [18:25:09] "1969" is nicer than "40221.525" [18:25:34] and the RTCC then has a conversion matrix stored [18:25:53] instead of always calculating the matrix on demand for e.g. conversion to the AGC [18:27:04] moon libration matrices and Earth precession/nutation matrices are generated just like the RTCC had them. [18:27:30] but they won't be used yet. Not until the RTCC uses the correct ECI and MCI coordinate systems [18:27:40] Earth equatorial instead of ecliptic [18:27:48] but that is all in place at least [18:33:38] nice :D [18:43:35] The biggest thing about FPGA programming is that everything is parallel and not sequential like you're used to. All the lines you write are executed simultaneously (usually). [18:46:50] the problem with wanting to support both Apollo and Skylab is, I am getting all the disadvantages and none of the advantage. On Apollo they changed the coordinate system yearly so that they could say "ah close enough, the Earth polar axis is identical to the z-axis of our coordinate system" [18:47:20] and starting with Skylab they said "we use a fixed coordinate system so that we don't have to change it anymore" [18:47:25] I still have some coursework about FPGAs lined up. So if you want to listen to someone ramble about VHDL hit me up. :P [18:47:32] I can do neither... [18:51:25] lol we still don't have any potential sources for Skylark yet either [18:53:24] yeah... but I don't want to be ready if we ever do :D [18:53:27] uhh [18:53:32] -don't [18:54:00] I don't want to change a lot of things and then they aren't future proof [18:54:19] and if we really never find Skylark, eventually we will start tinkering around with Artemis [18:54:44] lol that's true [18:54:56] fix its rendezvous programs for Earth orbit, move some stuff to erasable to support all launch years etc. [18:54:59] we at least do have that Norton document for Skylark, which should get us close [18:55:31] the additional rendezvous programs should be mostly interpreter, so I can help with that [18:56:28] there should in theory be a decent number of skylark modules out there, since that program flew on more missions than any other, and they all came back [18:57:39] yep [18:57:42] even more than Artemis [19:01:14] I don't know that we have to go into full Skylark reconstruction mode if we want to fly Skylab and ASTP [19:01:25] I think with some modifications Artemis will already be usable [19:01:42] it won't have the programs for 3 of the rendezvous maneuvers, which is sad [19:01:51] NC1, NC2 and NCC [19:02:03] but those can already be calculated the RTCC MFD [19:04:59] I remember Thymo wanted to look at fixing Artemis for Earth orbit, a few years ago :D [19:06:32] I did some work this summer. I've been implementing some of the PCRs that removed stuff. Trying to create some space for an eventual AAP mission like Skylab or Venus. [19:07:45] I ran into the issue when I tried flying the same rendezvous profile [19:07:55] I need enough space to port functionality from Superjob and then I need to replace NASSPs AGC implementation from yaAGC to magc once I implement the ACM and ATM for it. [19:08:20] the lambert aimpoint guidance calculations are not scaled properly for Earth orbit or something like that [19:08:37] so P34 and P35 can't give their numbers to P40/P41 [19:08:47] kind of important programs for the rendezvous... [19:09:05] if it was an easy fix then they got really lazy [19:09:21] even if there was no requirement for Artemis to do rendezvous in Earth orbit [19:09:29] they don't have to break it intentionally either :D [19:10:00] thewonderidiot, do we have any new memos from that time period? [19:10:29] the only ones that come to mind are ISS memos, which aren't really helpful [19:10:34] at least in this instance [19:10:38] I need to go through rendezvous school before I can start thinking about those kind of mofs [19:10:42] s/fs/ds [19:10:45] # COMMUNICATION TO THRUSTING PROGRAMS [19:10:50] # (1) TIG TIME OF THE TPI MANEUVER [19:10:54] # (2) RTARG OFFSET TARGET POSITION [19:10:58] # (3) TPASS4 TIME OF INTERCEPT [19:11:02] # (4) XDELVFLG RESET TO INDICATE LAMBERT (AIMPOINT) VG COMPUTATION [19:11:06] has to be one of those [19:12:28] "There is also a known problem [19:12:29] with the aim-point transfer between P34/F35 and P40/P41 when in [19:12:30] earth sphere." is all the program notes say [19:13:05] that gives us a pretty narrow area to look in the Norton doc [19:14:21] if we ever start looking at this seriously again I should first set up a scenario where the issue will happen [19:15:16] maybe after I get us LM131 and Comanche 67 :D [19:15:51] Hello guys! [19:16:15] hey [19:16:28] I am trying the reentry procedures [19:16:29] yo [19:16:48] During the descent to the sea, you have to purge the CM RCS helium [19:17:28] I do RCS logic on, and RCS dump and purge switches [19:17:39] My helium pressure is not decreasing [19:17:55] And the dump is not visible [19:18:10] you already dumped all the propellant? [19:18:24] all the engines are firing [19:18:47] I think not, because my pressure gauge reads around 3000 [19:19:00] hmm [19:19:02] \Scenarios\Project Apollo - NASSP\Apollo - Mission Scenarios\Apollo 7\Apollo 7 - 20 - At Entry Interface T+259h34m [19:19:10] I am using that scenario [19:19:23] might be an old scenario problem again [19:19:37] maybe the SECS buses don't all have power [19:19:44] CBs and logic/pyro switches up [19:19:46] Aha, maybe [19:19:53] Didn´t check that [19:20:00] scenario is already on the CM stage [19:20:07] although [19:20:17] shouldn't that be needed to deploy the chutes, too... [19:20:35] "CBs and logic/pyro switches up " Yeah, I think that is in good configuration [19:20:46] Because if not I would have crashed into the sea [19:21:13] Also tested this scenario: Apollo 7 - 18 - Before Deorbit Preparations T+257h19m [19:21:19] And same result this morning [19:21:48] HE dump doesnñt seem to work [19:21:55] *doesn´t [19:21:56] I'll check in those scenarios [19:22:02] Thanks very much [19:22:11] Saw the Alt+R :) [19:22:42] Auto RCS probably wouldn't work in the scenario either [19:22:47] unless you switch it on [19:22:52] Correct [19:22:53] for CMC reentry guidance [19:23:12] Had to do the little "hack" [19:23:53] for the purge it shouldn't really just need the RCS logic breaker [19:23:56] the RCS logic switch [19:23:59] and the purge switch [19:24:43] should really* [19:24:59] Yeah, that is what tyhe checklist says... [19:25:05] But "Nyet" [19:25:10] no purge... [19:25:25] Uploaded file: https://uploads.kiwiirc.com/files/76ad3806a33636f2a2ba95ec073dd15e/imagen.png [19:25:35] Buyt great views [19:26:17] well [19:26:23] and this [19:26:29] if (!purgeValvesOpen && purgePyroPower->Voltage() > SP_MIN_DCVOLTAGE && purgePower->Voltage() > SP_MIN_DCVOLTAGE) { [19:26:56] which is just the RCS logic breaker [19:27:00] and pyro bus again [19:30:04] the scenario doesn't have the pyro arm switches up [19:30:26] not sure if the checklist has you switch thos eup [19:31:42] I think it does... [19:32:26] Will fly it again not and check what you told me [19:34:46] flying it right now [19:35:01] I did switch up the pyro arm switches manually [19:35:08] but letting the auto checklist do the rest [19:36:00] not seeing it dump... [19:41:24] oh [19:41:32] yeah it's the old scenario [19:42:04] one of the weirdest parts of the sequential system [19:42:10] you know how you flip a switch during launch [19:42:13] when Mode 1A ends [19:42:42] propellant dump auto to RCS CMD [19:43:09] there is a timer that does the same thing, for redundancy [19:43:23] and if that timer doesn't run out the normal dump and purge are disabled [19:43:47] because it's thinking it might have to purge quickly, like during a mode 1A abort [19:43:55] and in old scenarios that timer didn't exist yet [19:44:28] that all seems like a very weird design, not being able to dump and purge if those timers malfunction. Have to look at that again if I understood correctly how it should work [19:44:46] but it's a problem just in old scenarios [19:48:27] Just in old scenarios... Ok [19:48:31] Good to know [19:48:45] yeah, the timer drops out when Mode 1A ends [19:48:53] I understand [19:48:57] and from then on the system is configured correctly [19:49:07] So this scenario -> Apollo 7 MCC - Launch.scn is fine [19:49:18] yes [19:49:42] anything before launch [19:51:52] Good [19:52:06] ah now I remember [19:52:13] the backup to this is [19:52:27] do crazy maneuvers with the RHC in all directions [19:52:36] to burn the propellant manually :D [19:53:03] the auto dump is definitely inhibited if the timer finish running [19:53:09] what about the purge... [19:53:29] Though of that :D [19:56:04] I think the purge is somewhat working, but the helium isn't really simulated separately [19:56:30] ah wait, yes it is [19:57:04] hmm [19:57:16] I think the purge happens through the thrusters [19:57:29] so you have to keep using the RHC [19:57:32] even for the purge [19:57:35] then it works [19:57:53] so you aren't stuck with the propellant and helium if the timers malfunction [19:57:58] just have to do an awkward procedure [19:58:42] looks kind of funny [19:58:56] instead of thruster firing effects you can control the purge effect with the RHC [19:59:04] Will try in a bit [19:59:48] I'll do a repair job on those scenarios, I can finish that by tomorrow [19:59:54] just a few essential relays, timers [20:00:03] the scenarios aren't totally broken [20:00:15] but this is one of those "a little bit broken" things too many [20:00:29] Aha [20:36:30] Uploaded file: https://uploads.kiwiirc.com/files/4b1847320b0de185ab7c9be8621c1a31/imagen.png [20:36:42] Dumping with RHC :) [20:46:31] fun [21:39:27] night! [14:24:29] hey Ryan [14:28:31] morning [14:36:24] how's 17 going? [14:38:18] Last rest period [14:38:29] Hoping to see the CMRCS temps a little higher [14:41:18] hey Niklas [14:43:31] hey [17:06:02] morning! [17:13:33] hey [17:22:11] seen any MSC internal notes on ebay lately? :D [17:34:22] haha I don't think so [17:36:54] was just looking through pics from auctions I had saved [17:37:00] and thought "I need more" [17:37:40] Man I just cant get these pitch jets to heat enough lol [17:40:57] I need to probably tweak the vector more [18:06:11] are the other cm thrusters okay? [18:11:50] Yes [18:12:06] coldest was 3.8 which is just below the heating temp [18:12:27] pitch jets were both 2.8 [18:14:36] might be the lack of conductive heat transfer getting us again [18:16:01] I have increased the vector size a little as a compensation [19:49:59] on the flip side, the RCS heaters seem to behave very well [20:05:15] we've had like 3 sources confirming the heating value haha [20:07:45] maybe it isn't a rare solution, but that was one of my favourite things I learned about the CSM this year. How do you heat the thrusters? You fire the thrusters (without letting propellants through) [20:12:28] yep! [20:12:39] makes sense as it acts as a backup [20:34:50] man if I dont get those mains off right away I end up sideways haha [20:39:26] n7275 other than a few suit compressor lights (it seems more sensitive now) I saw no ill effects from the changes [20:39:36] Hello everyone [20:39:39] afternoon [20:41:10] Got the GET´s for the TV´s! Thanks to indy91 , indeed they appear on the Apollo 7 summary flightplan and on Apollo Flight Journal [20:42:19] 1st: 71:44:00 "Keep those cards and letters coming in, folks" [20:42:25] ah nice [20:44:22] 2nd: 95:25 "Deke Slayton, are you a turtle?" [20:44:23] 3rd 119:05:00 "How to pee" [20:44:23] 4th: 141:14:00 "Daily Ritual" [20:44:24] 5th 189:04 [20:44:24] 6th 213:12:42 [20:44:25] 7th 237:19:35 [20:45:05] that's a lot of TV [20:45:18] And they cancelled one [20:53:16] I fixed the Apollo 7 mission scenarios btw. [20:53:29] but might be a bit late to update your NASSP install [20:53:44] also some minor RTCC changes in there [20:54:00] Oh nice [20:54:17] I am on 1751 [20:55:35] indy91 CMRCS heaters are ready for deployment [20:55:50] latest release is 1753... about to be 1754 I guess [20:56:06] and with you finishing the mission that ECS update should also be ready, right? [20:56:51] so two PRs to merge then [20:57:00] Yes I have tested n7275 with no issues on 3 missions [21:00:45] ok I am merging the ECS one [21:01:27] rcflyinghokie, the PR still wants your approval [21:01:39] I could merge it without of course [21:01:57] but I think your approval has slightly more weight in this case :D [21:02:04] I am trying to find the approval button [21:02:50] files changed [21:02:55] review changes [21:03:17] Ah I went to the bottom :P [21:03:25] ah ok haha [21:03:27] done [21:03:28] next one [21:05:14] looks like I have a forum post to write :) [21:05:23] with graphs! [21:05:34] Nice! I will have a tiny blurb to add :P [21:06:27] indy91, I had to prune out all my J mission stuff so if you see anything not right let me know, Thymo and I had a hell of a time with it lol [21:06:28] oh sorry, I could have given you a head start for writing that with the PR merging [21:07:02] @n7275 [21:07:38] I see the pressure equalization valve size also got increased [21:07:50] I think the last time we looked at that it caused some instability [21:07:54] too large valve sizes [21:08:07] but that was before we fixed the worst of the LM ECS instability [21:08:48] Yeah I have run this on 2 full missions [21:08:51] No issues [21:09:07] Just slightly decreases the time to pressurize the LM [21:09:12] Closer to actual [21:09:42] makes sense [21:10:24] I still forsee some more minor tweaks in ECS in general with n7275s changes, I have a few notes, but nothing is noticible unless you know what you are looking for (ie the LM glycol pressure being 21 instead of 23 now :P) [21:10:27] I don't remember everything about these SECS changes, but I think we got it right when we worked that out [21:10:52] Yeah I believe so, with respect to the CM RCS at least it all works properly [21:11:30] I'm not seeing any J-type mission remnants [21:11:34] looks all good [21:11:42] Ok good [21:16:30] merged, too [21:17:12] thanks, made a small blurb about it [21:21:57] did they do any preheating on Apollo 13? [21:22:02] costs a lot of power... [21:29:48] Should I keep on 1751 for Apollo 7? [21:29:55] indy91 yes I believe they did [21:30:51] but their power margins were good at that point [21:32:33] and I think the LM was still connected to MNB [21:33:36] TurryBoeing, I would say yes, unless you really want those fixed Apollo 7 mission scenarios as backup [21:34:44] I´ll stay on 1751 then [21:34:48] which you could always download separately [21:35:01] Yeah that is correct... [21:35:18] https://github.com/orbiternassp/NASSP/tree/Orbiter2016/Scenarios/Project%20Apollo%20-%20NASSP/Apollo%20-%20Mission%20Scenarios/Apollo%207 [21:35:38] Download them as raw... [21:36:05]