[20:01:58] NASSP Logging has been started by thymo [20:02:00] So [20:02:22] For some reason I'm completely incapable of opening ports on my network [20:02:46] However, my ZNC admin interface appears to be open to the internet. Which is not port forwarded at all. [20:02:53] I'm confused [20:04:21] Also, that port is only open on ipv6 and not ipv4 [20:09:54] hey Thymo [20:09:54] weird [20:10:05] What [20:10:23] So when I ssh to a VPS and I try to do a HTTP request on that port [20:10:42] I get a bunch of info from my modem. That's not what it should do [20:23:08] night! [12:04:11] Hey Alex [12:19:50] hey [12:48:53] Finally got everything up and running. Turns out that I disabled the firewall on my modem so DMZ and port forwarding settings stopped working. [12:53:07] ah, glad to hear [13:04:19] Now I finally have time to do the things I was planning on doing friday: Working on my C.V. for my internship and doing some more work for school. [13:10:04] nice [14:27:31] hey [14:30:48] hey Niklas [14:49:38] for the FC light, I think we just need to make the area of the FC cooling smaller [14:51:10] hmm [14:51:36] the cooling is only active when the FC temperature is at the upper end [14:53:24] I don't even know what is heating up the fuel cells, haha [14:55:09] ah, I think it's actually the cooling temperature that is measured [14:59:43] ok, there is a heat calculation [15:07:50] hmm [15:07:55] there are heaters [15:08:03] why are they not heating [15:11:50] they probably are [15:11:54] maybe not enough [15:12:01] but I don't always get the FC lights [15:12:03] just sometimes [15:12:10] temp is usually low at liftoff [15:13:02] yeah, same here [15:13:33] the batteries are actually pulling quite a bit of the load [15:13:35] more than the FCs [15:14:27] I think that is because the battery voltage is higher than the FC voltage [15:14:33] which probably isn't right [16:07:32] yeah [16:08:06] i [16:08:17] I imagine you'll be committing the LVDC fix? [16:08:19] ssss [16:08:44] hey TomTex [16:09:35] already done Alex [16:09:57] pushed [16:10:10] cool [16:10:58] Ive been trying all morning to find ways to make addforce not interfere with pad aborts [16:11:11] but without much luck haha [16:11:12] it's that one annoying timestep, right? [16:11:22] I guess yeah [16:11:42] hihi [16:11:48] one thing I thought of that could work is make a fake vessel, dock it to the saturn and put addforce there [16:12:00] and for the low FC temperature the reasons are probably: low overall load (why?), wrong battery/FC load sharing and then battery voltage drop with current [16:12:02] learning this program [16:12:03] but thats a bit overkill maybe [16:12:30] probably [16:12:53] I mean the goal is to dock it to the ML anyway [16:13:13] TomTex is trying to run some core files from NASSP in the Virtual AGC [16:13:18] indy91, you seem a bit busy with this project. another time i can cha tu? [16:13:23] no, it's fine now [16:13:32] oh ok [16:13:53] so what is the main goal in your project, I haven't fully understood that yet [16:14:08] was wondering about getting some core files [16:14:11] right [16:14:30] like cm and lm in lunar orbit [16:14:32] and trying to recreate some kind of simulator reset points [16:14:42] es [16:14:44] like the crews would have used during simulations [16:14:46] yes [16:14:59] you got it [16:15:08] doing that manually is rather annoying work, haha [16:15:24] i thing we are on the same page on some stuff [16:15:29] Even for missions where we have the right documentation I haven't tried setting up scenarios for NASSP with those exact state vectors [16:16:02] that flight crew simulator data document we have for Apollo 10 [16:16:06] it is painful so to speak [16:16:13] yeah [16:16:33] i got the a10 one [16:16:44] yeah [16:16:58] ust havent loaded into virtual agc [16:17:14] it does have a lot of good numbers [16:17:43] im interested in leveraging the agc to follow the flight plan [16:18:06] right [16:18:15] well you can do a lot with the standalone Virtual AGC [16:18:28] basically can i do the 10,000 keystrokes to the moon and back [16:18:31] but once you need any connected device, like engines, then it's not enough [16:18:56] oh. didnt get that [16:19:19] i thought it would sim that [16:19:20] the Virtual AGC doesn't simulate accelerometers, radars and all that stuff [16:19:27] NASSP simulates those things [16:19:49] are radars in nassp now, for rendezvous? [16:19:58] so maybe you want to use NASSP after all, in which case you are in the right place :D [16:20:11] yes, in terms of the Virtual AGC NASSP simulates everything now [16:20:13] ts been a while [16:20:48] i was an earl adopter of nassp then got caught up oing networks [16:21:12] NASSP has a stable release for Orbiter 2010 [16:21:16] simulating mostly Apollo 7 and 8 [16:21:29] i need a15 [16:21:51] then NASSP 8.0 Alpha version for Orbiter 2016 is your friend [16:21:58] its THE mission for me [16:22:17] it's a great mission [16:22:24] I have flown it already [16:22:26] i got space memorabilia in the hut here [16:22:30] I have a video from it [16:22:47] i saw the landig video [16:22:48] https://www.youtube.com/watch?v=E301HplyA7A [16:22:57] this is how it looks in NASSP [16:23:08] thanks [16:23:51] NASSP actually isn't developed for the Orbiter 2016 release version anymore, because we need some Orbiter Beta features [16:23:55] we have a installation guide: [16:23:56] https://www.orbiter-forum.com/showthread.php?t=40351 [16:24:52] Orbiter 2016 needs a fairly decent computer to run [16:24:58] and NASSP is very CPU hungry, haha [16:26:29] but it's the same Virtual AGC running of course [16:26:37] and many other systems [16:27:45] how many did it take to combine the two [16:28:04] you mean combine NASSP and the Virtual AGC? [16:29:16] yes [16:30:11] I have done most of that for the LM, in the CSM it was already mostly working when started helping with NASSP development [16:30:23] so I can only really speak for the LM part of that [16:30:23] i mean, can you do landmark tracking with the telescope in the cm? [16:30:32] it's been challenging and fun [16:30:35] yes you can [16:30:43] P22 [16:30:57] ow congratulations [16:31:02] it's not so easy to find landmarks in Orbiter though [16:31:14] was easier in real life I bet [16:31:25] was wondering about resolutuon [16:31:36] we actually found a bunch of bugs in the Virtual AGC when we started doing lunar landings [16:31:49] so the Virtual AGC has been great for NASSP realism, but we have been able to give back [16:31:51] really [16:32:07] thats coool [16:32:38] with the high res textures for the Moon in Orbiter 2016 you can see a lot on the surface [16:32:41] the learning curve for nassp now has me concerned [16:32:53] if the lighting is good and you study the maps you can often find the landmarks [16:33:05] yeah, it is a very difficult simulation with a lot of things to learn [16:33:15] and I guess you are mostly interested in the AGC, right? [16:34:00] i do net eng and am now caught up in virtualization so my time and brain can only last so long [16:34:13] yes [16:34:48] the 'nauts didnt have mfds [16:35:00] ust that agc [16:35:11] they had something much better and competent, mission control, haha [16:35:27] can u fly a mission without mfd only agc? [16:35:36] yes and no [16:35:39] true [16:35:40] you can fly without MFD [16:35:54] we have an automated mission control feature that does all of the calculations for you [16:35:57] have you [16:36:06] you just have to accept uplinks and execute maneuvers [16:36:12] cool [16:36:23] but only for Apollo 7 to 11 right now [16:36:32] so kinda like the real deal [16:36:43] yeah, pretty much [16:36:55] for the other missions we have to use MFDs to do calculations etc. [16:37:04] its been a while for me [16:37:09] AGC only is not possible [16:37:22] it has to capability to calculate several important maneuvers [16:37:31] LOI and TEI for example [16:37:35] so you take mfd data n plug into agc? [16:37:55] AGC needs numbers from the ground to execute maneuvers [16:38:08] yeah, but the MFDs also can do uplinks [16:38:25] but some things have to be done with the DSKY of course [16:38:32] so basically V71 [16:38:33] can't uplink everything, haha [16:39:13] yeah, uplink is uplinking DSKY inputs basically [16:39:35] is there alot of panel toggle switch stuff to do? [16:39:45] almost all of it [16:40:02] yikes. maps? [16:40:06] most switches and circuit breakers in NASSP have a function now [16:40:20] what kind of maps do you mean? [16:40:28] how do u find them all [16:40:49] what maps? [16:40:54] where is so n so? [16:40:58] oh [16:41:03] well the panels are numbered [16:41:28] NASSP has 2D panels so you need to switch around between them [16:41:44] im ok w that [16:42:05] so if you know which panel a switch is on and you know your way around then you will find the switch [16:42:18] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Doc/Project%20Apollo%20-%20NASSP/Crew%20Module%20Panel%20Overview.pdf [16:42:20] we have this [16:42:23] but it's outdated now [16:42:35] added some tunnel stuff in the middle [16:42:41] how does one learn ? t [16:42:49] hunt n peck? [16:43:17] what about the lm [16:43:31] yeah, it's difficult in the beginning but you learn over time [16:43:41] definitely a steep learning curve [16:43:52] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Doc/Project%20Apollo%20-%20NASSP/Lunar%20Module%20Panel%20Overview.pdf [16:44:07] thanks [16:44:10] luckily the LM doesn't have quite as many switches and circuit breakers as the CSM [16:44:36] are bones spaceship that lm [16:44:42] bare [16:45:24] different concept between those spacecraft for sure [16:45:37] probably a weight saving thing [16:45:41] in the LM [16:45:42] thanks for invite to this chat. very informative [16:45:56] yeah, feel free to stop by if you have any questions [16:46:09] h i will [16:46:14] So, do you want to play around with the Virtual AGC first? [16:46:31] I can give you some core files [16:46:40] i need to land and lunar rendezvous from Hsdley Rille [16:46:43] but as I said, they are limited in what you can do [16:46:58] yes [16:47:17] so if you want to limit the stuff you have to learn you could start with the LM only [16:47:18] mostly lunar ones [16:47:22] indy91, just making a PR with a small adjustment to the Saturn 5 td points, should make it more stable with accidental SM RCS firing during 10-50x time acceleration [16:47:30] sounds good, Alex [16:47:38] sent [16:47:52] ok lm it is [16:48:06] for Apollo 15 we only supply a prelaunch scenario with NASSP [16:48:17] but I can you give you one from shortly before PDI [16:48:31] or if you want to do the LM activation procedures as well, you can do that, too [16:48:34] hat would be awesome [16:48:50] checklists availability is very good for Apollo 15 [16:48:55] pass on activate now [16:49:37] so is this nassp scn or vagc solo core? [16:50:21] NASSP scenario. But I just have to hit a button and save a core file from a Virtual AGC running in NASSP [16:50:44] P63 for example works in the Virtual AGC until ignition [16:50:49] mind sendind both? [16:50:51] then it detects a thrust failure [16:50:56] can do [16:51:07] let's see what I have [16:51:19] when it comes to scenarios I am a hoarder [16:51:21] cool [16:51:30] latest set is from a mission AlexB_88 has flown [16:51:39] no. archiver [16:51:50] PDI minus 10 minutes sounds good [16:52:03] ok [16:52:28] and it's running P00, very good [16:53:05] PDI P30 already done ? [16:53:18] P63 needs no P30 [16:53:26] different set of calculations [16:53:30] rusty [16:53:46] first thing P63 does is run an ignition algorithm [16:53:52] determining the time of ignition [16:54:04] so you could say it has a build-in P30 [16:54:38] flight manual follows tose time close maybe? [16:54:54] the core [16:55:14] probably close [16:55:29] in any case the scenario (NASSP and Virtual AGC) are from 10 minutes before PDI [16:55:37] the checklist you want for that is the LM Timeline Book [16:55:37] ok. that would ease my entry learning [16:56:10] ok. im familiar w it [16:56:24] https://readux.ecds.emory.edu/collections/emory-control:LSDI-Apollo15/ [16:56:38] David Scott had ALL his personal checklists from 15 scanned and put here [16:56:51] very awesome for us [16:57:09] i found that the other day n was wondering if u had [16:57:21] https://readux.ecds.emory.edu/books/readux:spgjt/ [16:57:27] this is the one [16:57:35] i was trying to remember to ping u on that [16:58:11] 10 minutes before PDI is on page 6 of that [16:58:15] Powered Descent Initiation [16:58:18] with the "-10" [16:58:55] thanks [16:59:14] not always easy to read, very abbreviated notation in the checklist [16:59:34] https://drive.google.com/open?id=1RItELNynsd4u3jZK4F24Hb1OeJV1hkxq [16:59:37] here you go! [16:59:42] meat n potatoes [16:59:52] core file and scn for NASSP [17:00:54] any flaws in that scenario is the fault of AlexB_88, no liability [17:01:23] "don't use for real space flight" [17:02:54] ha ha [17:03:17] ill keep my personal LM parked [17:03:44] downloaded fine. thank you much [17:03:48] what Apollo 15 memorabilia do you have? [17:03:57] lots [17:04:08] star maps 6 [17:04:23] lunar track land map 1 [17:04:34] https://www.hq.nasa.gov/alsj/a11/A11StarCharts.html [17:04:35] lm timeline book [17:04:36] like this? [17:04:41] waaaaait [17:04:47] you have a LM Timeline Book? [17:04:52] yep [17:04:56] not the flown one I guess [17:05:02] in bank safe [17:05:08] no [17:05:20] a16 [17:05:49] i love seeing the Touchdown statement in it [17:06:09] a big decal [17:06:31] orbit maps almost all except a13 [17:06:57] pretty impressive [17:07:15] im old enugh to remember those days as a kid [17:07:36] ebating auctions [17:07:57] but i need want to use them w nassp [17:08:19] auctions are kind of bitter sweet for us [17:08:30] brings a heightened realism to it i hope [17:08:31] they often post a few pages from a document [17:08:52] so if we were searching for a specific checklist then a few pages are already nice [17:08:57] what do u mean [17:09:30] ideally for NASSP we want to have scanned versions of every Apollo checklist that ever flew [17:09:31] im worried about the bindings on my 3 Delco books [17:09:42] because we can use all the checklists [17:09:53] thats a BIG list [17:10:00] yep [17:10:19] a trip of a week to houston to scan [17:10:20] so whenever something we don't have pops up in an auction I am happy about a few new pages [17:10:39] but I am also thinking "can you scan this first and then sell it?" :D [17:10:52] I think that is what David Scott is doing [17:10:58] ight. [17:11:08] made everything he has from Apollo 15 available as scans [17:11:29] i know that was cool of him [17:11:41] yeah, definitely [17:11:46] I have contacted the owners of some checklists in the past and asked about specific pages [17:12:02] industrius [17:12:03] just to figure out a specific procedure [17:12:20] NARA has the complete flight data files [17:12:29] but it would be very expensive [17:12:36] your a real go getter on this stuff [17:12:57] we go to great length, yes :D [17:13:15] cheap flight cheap hotel cheap usb sticks [17:13:24] expensive scanning [17:13:25] usb is free there [17:13:41] oif u scan yourself [17:14:12] m thinking a week vaca to do it is the most cost effective way [17:14:12] right, I think that still applies [17:14:30] Ron Burkey has been doing that a lot with AGC schematics [17:14:39] otherwise buy the real deal [17:14:48] not cheaper :D [17:14:58] they took a diff tack [17:15:07] requests, so if you are not personally there, have gotten more expensive [17:15:12] mechanical model [17:15:31] and I am in Germany, so flight is not so cheap :D [17:15:48] oh. im in Utah [17:15:51] usa [17:16:07] inda close to houston [17:16:14] I think Ron lives fairly close to Fort Worth, so that helps him [17:16:25] im seriously thinging about going [17:16:42] for what specifically? [17:16:52] its actually NARA in ft worth [17:17:12] apollo 15 soup to nuts [17:17:42] yeah, NARA - Fort Worth is where most of the good Apollo stuff is [17:17:57] esp that sim data but hunt for uplinked records of state vectors [17:18:06] NARA Atlanta has documentation from Marshall Space Flight Center [17:18:36] unfortunately I have never seen any uplink/downlink data [17:18:38] really. thing thats a better bet for state vectors? [17:18:52] an erasable memory dump printout would be awesome [17:18:57] basically the same as a core file [17:19:13] they reused those computer tapes apparently [17:19:23] yeah, probably not much left [17:19:47] Fort Worth is the place for us [17:20:01] yes. exactly. Mem dump would be ideal [17:20:02] Marshall would be relevant for the LVDC [17:21:23] hmm [17:21:35] so, I have some good documentation from Apollo 15 that you might not have seen [17:21:46] or actually, one of those I already had linked to you, I think [17:21:47] i yeah? [17:22:21] ftp://ftp.sciops.esa.int/pub/ekuulker/Apollo15_Navigation_Results.pdf [17:22:35] well u have been a godsend for me to reenter the vagc and nassp areas [17:23:51] yep got it but its a lot of delta correction stuff. very little initial values like Vx Vy Vz [17:24:09] and not necessarily the right coordinate system either [17:24:30] Apollo 16 had some comm problems, so they did some V71 manually [17:24:40] howd u learn english so well [17:25:51] thats good to know. maybe a radio transcript would be in order, air to ground [17:26:27] everybody under 50 speaks good English in Germany. Everybody older speaks very little, haha [17:26:30] search G&N [17:26:54] the transcripts are out there [17:27:13] and the Apollo Flight Journal is a nicely formatted version of it [17:27:23] i did that already on one and only got a few V71 [17:27:56] ive been hunting. trust me [17:28:23] ah, found it [17:28:25] https://history.nasa.gov/afj/ap16fj/14_Day5_Pt2.html#094_41_50 [17:29:01] so that's a proper state vector [17:29:32] and Apollo 7 also did some manual upates [17:29:36] just for testing purposes [17:31:48] yes [17:32:51] I'll be back in a bit [17:33:07] ok later [17:52:31] Ill have to get around to downloading those Apollo 15 checklists [17:52:54] I did it immediately when they became available, haha [17:53:05] you never know when they take something of the Internet [17:53:07] like NTRS... [17:53:16] I wanted to, but at the time I had major speed issues with my ISP [17:53:22] yeah, it's large files [17:53:27] it's not the complete FDF [17:53:37] missing some CMP specific checklists [17:53:49] CSM rescue book for example [17:54:03] right [17:54:58] my favourite thing was the LM Contingency Checklist [17:55:04] with the 30 minute LM activation procedure [17:55:14] for a specific LOI failure mode [17:56:10] Ill have to try that [17:56:37] very fun, very challenging [20:39:23] night! [11:59:36] morning [12:15:43] setting up for an Apollo 10 run [12:54:58] hey Alex [12:55:16] I was messing around with fuel cell and battery voltages as a function of current [12:55:36] I think I have a good improvement, unfortunately it makes the voltages fluctuate [12:56:33] when FC and battery are both supplying power to a bus then they are sharing the power load based on voltage, all while their voltage is chaging with power load [12:57:36] it's not instable with timestep length or anything, they just change voltage every other timestep [12:57:51] probably going back and forth between two stable values [12:58:08] sooo, I'm probably not implementing this [13:00:03] it would give the fuel cells a larger share of the power load on liftoff and so the temperature would be higher [13:02:38] ah nice, too bad it fluctuates [13:02:59] the change would probably also help with the LM batteries [13:03:09] a higher voltage with low power [13:03:20] maybe I can still use the battery calculation [13:03:44] the fuel cells have a fixed 28.8V right now [13:04:30] batteries on the other hand already were having a voltage drop with higher current [13:04:39] just not realistic enough for a lot of cases [13:05:25] yeah, I'll see if I can at least implement the battery change [13:07:45] nice [13:08:02] in other news, looks like MS flight sim is back [13:09:13] yeah, I saw that [13:09:42] following the current trend of leaving out any version number [13:09:58] yeah [13:10:41] looks pretty good, we'll see next year [13:12:31] yeah, it looks amazing graphically, hope the same can be said "under the hood" [13:13:25] it's still going to be the addons that have the high end realism I guess [13:14:00] yeah [13:14:30] oh found a small issue on my initial Apollo 10 scenario. It seems the MTVC does not read the joystick during the MTVC test on the pad, but it works when save/reloading [13:15:02] ok [13:17:27] I would imagine that is some joystick init issue [13:17:37] rather than simulation [13:17:39] but I will check [13:18:17] My other functions were working I think, the RCS was firing and such [13:18:57] so maybe SCS [13:24:12] oh, maybe the instability was due to a bug I introduced [13:25:24] hmm, no, that would have been nice [13:37:50] restart, brb [14:30:52] making some fresh Apollo 10 scenarios [14:31:31] great [14:31:44] I found the source of the instability, it's different than I thought [14:32:04] there is a diode that only lets the batteries power the main buses, if their voltage is higher than the FC voltage [14:32:15] but in our cases that is a direct on/off switch [14:32:27] so the batteries are taken off the main buses on every other timestep [14:32:55] battery with zero current has a high voltage, then gets connected, voltage drops below threshold, disconnect, repeat [14:34:02] what would be realistic is beyond a certain power load the batteries gradually contribute a share of the power load [14:35:50] didn't happen before because FCs had constant voltage [14:35:59] and battery voltage was always higher than that [14:40:57] right makes sense [14:43:46] not sure how I solve this in a satisfying way [15:48:08] yeah [15:48:26] now to try my 1st LM pressurization at the correct time :D [16:11:07] ah that went quite smoothly, now things after LM ejection are quite relaxed [16:25:24] great [16:25:30] a few fun facts from EPS research [16:25:40] the SPS gimbals are powered by the SM buses [16:26:49] so I am not sure Apollo 13 would have been able to use the SPS [16:26:52] due to dead fuel cells [16:27:02] not because the SPS might have been damaged [16:27:21] the aux battery they added from Apollo 14 on can powered the SM buses [16:27:30] and it's a LM descent battery! [16:28:20] interesting [16:28:29] I was a bit confused at first when I saw references to LM flight data in the aux battery graphs in the CSM Data Book [16:28:41] but it simply is one of those [16:29:42] so we definitely should add SM buses at some point [16:29:58] right now we don't have separate SM buses [16:34:08] a not so fun fact, I am cancelling the FC/battery voltages update for now [16:34:16] looking into your MTVC issue instead now [16:45:21] when is that in the checklist? [16:54:13] near the beginning of the prime crew ingress checklist I think [16:55:50] in the "final verification & systems checks" [16:56:03] ok [16:56:09] it only didnt work when I hadnt saved/reload yet [16:56:13] right [16:56:30] I'll try without a connected joystick first [16:56:36] just to see if it's a SCS issue [16:59:56] oh and once again LVDC navigated nearly flawless, 70 km error at insertion [17:00:01] meter** [17:00:10] don't make my heart stop like that :D [17:00:20] haha sorry [17:00:28] I like 70 meters [17:00:34] 70 km would be a bad day haha [17:01:27] probably [17:01:59] there are procedures for that I bet [17:02:10] depending on safe or unsafe perigee [17:02:22] right [17:03:29] ground calculated apogee kick [17:03:41] TLI sv accuracy was pretty good to about 600-700 meters, but I think that is partly due to the SV update [17:04:29] yeah, I think that is a usual number for that [17:05:06] ah, you are doing Apollo 10 [17:05:14] I should have done that in case the checklist is wrong [17:05:17] I'm on 11 right now [17:12:24] ok, confirmed not working [17:12:26] now reloading [17:12:37] and it's workintg [17:12:42] SCS issue then [17:15:24] I made the SCS TVC just a tiny bit more complicated recently, so might not be so easy to figure out :D [17:29:35] haha I bet [17:30:38] so far I am making a list of the checklist issues on 10, not to bad so far, just things like unneeded V66, uplinks not aligned with MCC [17:30:46] good [17:30:56] so, there is one thing I discovered already [17:31:01] RHC 1 vs RHC 2 [17:31:10] we only have RHC 1 inputs right now [17:31:19] but the TVC checkout procedure uses both [17:31:47] in the first part of the checkout the MTVC shouldn't work, because it is using RHC 2 only [17:31:57] so it working after reloading is the bug really [17:33:28] we can't really make the rotation control input both RHCs at the same time [17:33:39] that would command twice the normal rates for some parts of the SCS [17:38:19] hmm [17:38:34] MTVC doesn't work in any mode though before reloading, so there is more to it [17:45:02] I think the thumbwheels can make it work [17:45:10] before reloading [17:52:24] it's SCS logic power [17:52:40] SCS logic power 2/3 switch [17:52:58] I think it's an order of operations issue [17:53:19] it doesn't connect logic bus 3 (and probably 2) right in all cases [17:53:58] so when you initially load the launch scenario it isn't in SCS mode [17:54:03] even thoguh the SC CONT switch is in SCS [17:58:38] the switch starts in on [17:58:58] but the buses only get connected right now when you switch to Up or on loading [18:00:30] I think it's an easy fix [18:00:38] the class for the switch has no own Init function [18:00:53] but it needs one to initialize the connected buses right [18:11:09] fixed [18:13:06] fix pushed [18:21:30] awesome, nice find [18:27:55] paradoxically, now that I have made MTVC work, I need to figure out why it should even be working [18:28:12] maybe I made some concession considering that we don't use RHC-2 yet [18:28:33] so that MTVC works in all cases where RHC-1 or 2 would be working [18:32:22] yeah that would make sense for how its setup now I guess [18:35:52] I think I was just confused, both RHCs will work with either TVC servo [18:36:08] they are just testing RHC-2 in the first part of the prelaunch procedure, and RHC-1 in the second [18:36:19] so it's all working right now I think [18:42:25] great [18:43:04] there is a bunch of wiring stuff I still need to do if we implement the second RHC properly [18:43:08] but other than that, haha [18:46:30] yeah, I guess not a priority right now [18:47:23] useful for very few things [18:47:33] like CM RCS translations [18:50:13] right [18:50:42] or if you misplace RHC-1 [19:01:17] MCC-2 is 33.5 fps [19:01:31] reality: 48.7 fps [19:02:12] and its your fault, you made the LVDC too accurate :p [19:04:46] actually on Apollo 10 it's the least accurate [19:05:03] DV might be low, but you will be late in lunar orbit [19:05:19] and with MCC-1 being skipped it's up to 20 minutes late iirc [19:10:00] ah, right [19:18:09] for the real Apollo 10, was that a result of a bad IU state vector, or was it an issue with the presettings? [19:19:34] oh and here's a cool pic I took: [19:19:35] https://www.dropbox.com/s/szz051h5xfxoav8/Screenshot%202019-06-10%2012.34.06.png?dl=0 [19:25:46] it's our presettings [19:26:00] I had better sources for those for most other missions [19:26:26] well, the flight evaluation report and the postflight trajectory for all missions, but they contained different numbers for Apollo 10, not quite as useful [19:26:46] yeah, it's always fun watching the S-IVB shoot off into the distance :D [19:31:57] yeah [19:33:02] wearing my Ray Bans for this MCC, got me pointed right at the sun [19:35:23] 025:40:38 Duke: Roger. 013 and 018. And you're going to be - In the burn attitude you're going to be looking at the Sun. The Sun is 4 degrees off from the X-axis, and we think with this roll angle that the LM will block it out completely, though. [19:38:30] sorry that my MCC didn't you find a good roll angle :D [19:38:35] yeah, my burn attitude was similar to theirs [19:39:18] I guess they used 99 roll, I used 90 so it wasnt far off [20:07:20] Apollo 10 flyby RTGO is 930.9 NM is that correct? [20:10:19] doesn't sound right [20:10:27] 1,180.4 on the real one [20:10:38] sounds like that issue I had with TLI+90 pad on 11 [20:10:48] yeah, probably a simple RTCC fix [20:11:49] https://github.com/dseagrav/NASSP/commit/0b4ad03dd3f7803374d6dccb91753ceb2187d6c1 [20:11:58] maybe the same for 10> [20:12:00] ? [20:12:29] ah sorry, https://github.com/dseagrav/NASSP/commit/110ef12351974ef5cd23089d110e8f6f40cdb276 [20:12:47] yes [20:14:24] entopt.r_rbias = 1285.0; [20:14:35] those lines in all the places where RTEMoonTargeting is used [20:15:47] I can quickly commit and push that [20:15:56] ok [20:16:41] done [20:17:29] ah damn, I also need to add the higher entry speed constraint for the PC+2 I guess [20:18:14] ah the u_rmax thing [20:18:21] yes [20:18:38] or else it will constraint the return speed to the normal 36323 or whatever it is [20:18:39] I was wondering what that was lol [20:18:43] right [20:18:50] should be 37500 ft/s for those contingency returns [20:45:13] night! [16:22:28] good evening [16:27:49] hey Niklas [16:29:11] kept too many development branches, haha [16:29:27] I've deleted some, merged others, I'll do a bit of testing and then commit it [16:29:30] nice [16:29:57] it looks like they didnt even run P63 at all on Apollo 10, im surprised [16:30:17] and I screwed up the Apollo 8 checklist, so I had to copy the one in the github repo [16:30:18] I would of thought they would of at least made a pass through it [16:30:25] yeah [16:30:32] I will of course :D [16:31:06] so, the preliminary descent/phasing summary document has a P63 test [16:31:07] and LR test [16:31:09] btw do you mind committing that PC+2 constraint thing? My PC+2 calculation failed because of it [16:31:32] but in the end they didn't do that I am pretty sure [16:32:07] I've commited it locally already [16:32:14] ah ok [16:32:15] entopt.u_rmax = 37500.0*0.3048; [16:32:19] this is what you need [16:32:33] enter that in line 725 of RTCC_Mission_F [16:32:37] thanks [16:32:55] if you run P63 with Luminary069 you need to reset some flag [16:33:13] it switches to the P63 Average G routine but doesn't switch back when you go to P00 [16:33:14] The Apollo 10 checklists will need a few fixes, I can make them when I finish the mission [16:33:16] that's a bug [16:33:21] fixed in Luminary099 [16:35:02] ok [16:35:10] anywhere I can find that procedure? [16:35:55] ah, well Im going to run it, to try a landing, not go back to P00, so no need I guess :D [16:36:42] we never got the landing radar working with Luminary069 [16:36:52] otherwise it works ok [16:37:01] V25 N07E 102E 200E 0E [16:38:51] I've done P63/P63/P71 in the past [16:38:54] P64* [16:39:17] ok [16:39:25] Im up to DOI on Apollo 10 [16:39:40] like you said, 20m late [16:40:00] 10 minutes of that is skipping MCC-1 [16:40:06] the actual mission had that too [16:40:19] but something must be a bit off with the TLI presettings [16:40:34] yeah [16:43:36] you had given me in the past modified values for the Apollo 10 MCC: [16:43:57] LSAzi = -90.0*RAD; [16:44:04] instead of -91 [16:44:13] but I forgot to add those for this run [16:44:57] anyways, I have to go out for a bit, cya in a few [16:46:10] vya [16:46:12] cya* [16:48:00] I don't remember that. My sources say -91° is right. Why 90? [16:59:15] morning! [16:59:20] hey [17:42:49] trying to figure out if there is a way around the issue [17:43:08] but probably not [17:43:21] yeah I don't think so [17:43:26] just have to do it the right way [17:43:35] or use a patched rope that doesn't have that test [17:43:41] but, butter to do it right :D [17:44:55] yeah [17:45:25] the code talks about bit changes, so if the appropiate IMODES33 bit already has the PIPA fail then it might not come up again and again [17:46:05] I can test that in NASSP [17:46:14] just in case [17:48:35] sure :D [18:33:59] back [18:35:19] indy91, I think last August or so you had given me this procedure: [18:35:22] in the MCC project there is a file called RTCC_Mission_F [18:35:22] line 45 is [18:35:23] double LSAzi = -91.0*RAD; [18:35:23] change that to 90, maybe [18:35:24] -90.0 [18:35:24] and then hardcode the approach azimuth for LOI and REFSMMAT [18:35:25] line 598 change LSAzi to -91.0*RAD [18:35:27] same in line 754 [18:35:29] that makes sure that LOI and the LS REFSMMAT actually use -91 [18:35:39] I hadnt actually tried it yet though [18:36:07] I think the goal of that was to try and get a time of arrival closer to reality [18:38:23] hmm, right [18:38:26] vague memory [18:40:03] thewonderidiot, PIPA fail is super persistent in getting reset [18:40:18] Virtual AGC also doesn't allow writing to it from the outside [18:41:14] but it doesn't stop me from running P63 [18:41:43] hmm, really? [18:42:00] yeah, I can make it persistently cause me a 212 alarm [18:42:04] but P63 works [18:42:07] oh cool [18:42:13] did you get the blinking V37 and all? [18:42:27] and I also get 212 alarm in P00 [18:42:44] I think I may have just stopped and not tried P63, after the 210 totally prevented me [18:42:57] yeah, 210 throws you out of P63 I guess [18:43:02] I might have figured 212 would be the same [18:43:09] well that's good to know :) [18:43:11] thanks! [18:43:16] well, I hope it applies [18:43:25] not just to Virtual AGC and NASSP, haha [18:43:27] only one way to find out [18:43:31] yeah [12:49:22] tried Apollo 11 PDI with the new DPS erosion, landed with 6-7 % fuel [12:49:42] yeah, I had 6.1% [12:50:41] back in a bit [13:08:23] the next change I want to make is slow down all our uplinks to 0.1 characters per second [13:08:39] that's half the speed we are currently using [13:09:24] and then I want to look at the old switch selector function we still have for Saturn IB and V [13:09:41] there is some stuff I couldn't move easily, like playing sounds, prelaunch venting etc. [13:10:02] that is still commanded by the LVDC, which is of course quite wrong [13:10:38] so I was watching some launch videos to figure out how the venting looks [13:11:44] the S-IVB has so many different vents, I haven't figured out yet which one is the one used before launch [13:24:53] I did think the uplinks were a bit fast :D [13:34:37] one thing I thought that we could do soon is a crew status class for the LM [13:34:43] like the CSM has [13:36:52] yeah [13:39:24] hmm it doesn't look to hard to use the same code from the CSM, I think Ill give it a try [14:30:53] ok got it transferred and working, for now just accelerations & touchdown speed exceedances are activated, still have to figure out where to get the CO2, suit press/temp values from [14:31:35] CSM used: [14:31:36] AtmosStatus atm; [14:31:37] saturn->GetAtmosStatus(atm); [14:32:00] then used atm.SuitPressurePSI etc to call the data [14:34:02] I could probably make a LEM_ECS::Getxxx() function that gets the required data [14:34:14] yeah [14:37:41] the LEM class should also have pointers to the crew [14:39:03] right [15:09:35] so, just thinking about the logic...I thought of making it like this, if both CDR & LMP are in cabin, then cabin PSI/temp will be controlling, and if either one or both are in suit, then suit PSI/temp will be controlling. Hows that? [15:10:36] ideally we would have separate CDR & LMP alive/critical/dead states, but maybe thats overkill [15:18:03] sounds good [15:44:07] ok got the logic done [15:44:54] so about the pointers to the crew you mentioned, do you have an example of that? [15:46:23] well, if you need the crew itself and not the "tanks" that are connected to the crews [15:46:59] CrewInCabin, CDRSuited and LMPSuited [15:47:12] are the pointers in the LEM class [15:49:36] ah ok [15:50:19] when the DCR is in EVA, what is he considered, in suit? [15:50:29] as far as the ECS is concerned [15:50:36] or is he just completely gone? [15:50:41] CDR* [15:51:19] gone [15:51:23] ok [15:51:47] we have a LEMECSStatus [15:51:55] cdrStatus == 2 is EVA [15:53:52] yeah I use that at the top of LEMCrewStatus [15:59:59] hmm I get a flickering ECS light whenever I depress the LM cabin [16:00:16] its not related to the cabin press light [16:00:20] uh oh [16:01:54] hmm [16:02:13] if the condition persists that would have the ECS light on then it should just stay on, not flicker [16:02:50] I wonder if I got the if/else stuff wrong [16:03:08] I don't see how [16:04:54] can you cause any condition that keeps the ECS light on? [16:05:32] without flickering [16:09:46] ah, no [16:10:15] I might have tried to be too fancy with leaving out brackets [16:10:52] yep [16:11:07] I don't quite understand how it doesn't cause a compiler error, but that is what I did [16:11:20] if (lightlogic) [16:11:21] if (ECSFailureCount < 20) ECSFailureCount++; [16:11:22] else [16:11:22] ECSFailureCount = 0; [16:11:23] that is bad [16:11:32] if (lightlogic) [16:11:33] { [16:11:34] if (ECSFailureCount < 20) ECSFailureCount++; [16:11:34] } [16:11:35] else [16:11:36] { [16:11:36] ECSFailureCount = 0; [16:11:37] } [16:11:40] this is good [16:12:03] it probably associated the else with the 2nd if, not the 1st if [16:12:38] morning! [16:13:11] yeah every job I've worked at has explicitly forbidden leaving out braces because of stuff like that, haha [16:13:26] there is a phrase for it [16:13:27] https://en.wikipedia.org/wiki/Dangling_else [16:13:41] I can understand why [16:14:04] did we tell you yet that we can do lunar landings with Luminary069 now? [16:15:04] no! you found the radar problem? [16:15:08] in the past we followed an older version of the checklist which had the LR spurious test running, which is messing with LR bits and data. So in the past we always had LR issues. [16:15:21] ahhhhhhh [16:15:24] just had to stop that extended verb from running in the background [16:15:24] checklist error :D [16:15:30] awesome [16:15:36] that is very good to hear [16:15:39] in Luminary099 and later the test is stopped automatically with a V37E [16:15:46] not in 69 [16:16:07] I had no idea it was still running until I went through all the flagwords and found that it was set [16:16:29] Alex flew a new Apollo 10 mission with updated checklists and it worked immediately [16:17:04] with the test running the LR always showed data good, but with a measured altitude of 0 all the time [16:17:12] so LGC thought data was good and incorporated that [16:17:56] AlexB_88, I'll have a fix for the flickering in my next push [16:18:05] ok great [16:20:10] Alex, can you quickly try the Apollo 8 T-60s scenario and listen to the sound at liftoff? There are two separate sound files running, one up to liftoff and one after liftoff [16:20:21] and it sounds like the "0" comes right after "1" [16:20:29] as in T-1 and T-0 seconds [16:20:48] but I might have screwed up the timing somehow, so I'd like to know if that is already the case [16:20:54] if that was already* [16:21:13] basically, the timing doesn't sound right [16:21:43] the T-10s and counting sound file used to start at -10.9, but was changed to -10.3 at some point [16:23:40] sure [16:24:33] thewonderidiot, and I can't really blame a checklist error because the checklist never intends to run P63 further than the ignition algorithm :D [16:25:01] and the newer checklist never intends to run P63 at all, pretty sure they didn't use P63 on Apollo 10 [16:25:03] indy91, yep I confirm [16:25:28] the very old timing works great [16:25:35] no idea why it was changed [16:27:04] it was changed before we started using Github, so difficult to track that down [16:28:19] but I think I'll change the start of the sound back to T-10.9 when I move it out of the LVDC code [16:37:25] even if, for some mission, -10.3 is better a short delay from -1 to 0 sounds much better than it being too close together [16:52:49] makes sense [16:52:51] ok I am getting close to something good for the CrewStatus class in the LM [16:53:15] one thing though is that temperatures is still something that is not easy to get stable in the LM [16:54:00] so right now it is easy to kill the crew by frying/freezing them. For that reason I think I will leave the temperature logic commented until we get that more stable [16:54:08] yeah [15:48:55] morning! [15:49:29] hey Mike [15:49:52] what's up? [15:50:37] just finished some mesh fixes [15:50:58] and you? [15:52:27] thinking about writing some new AGC test code [15:52:42] and pondering ways to send data into it [15:55:49] nice [15:56:20] hows the situation with the simulated CDUs? [15:56:32] haha, haven't worked on it for a bit [15:56:46] but I will get back into it probably next week [15:56:57] I guess its a big task [16:26:53] there we go [16:27:04] I've written a test that can't pass on virtualagc right now [16:27:39] now to see if it works on real AGCs... [16:57:23] yep :D [18:02:53] good evening [18:05:18] hey [05:01:39] .tell indy91 my erasable dump processing script had a bug in it that corrupted all of the data. I just reprocessed it and it is almost guaranteed to be from Aurora 88 [05:02:29] .tell indy91 here's what is in DSPTAB -- looks like they were doing a coarse alignment test: https://i.imgur.com/1PYFwRX.png [05:02:52] .tell indy91 the phase tables are shifted up one location from Aurora 12, so other things before or after them may have shifted too [05:04:08] .tell indy91 here is the corrected dump if you want to see if it makes any more sense. sorry for the bad first one! https://gist.github.com/thewonderidiot/382aea82242930868bb3a473650703d3 [16:01:58] good evening [16:04:17] hey Niklas [16:05:01] morning! [16:05:47] my intuition was right, haha [16:05:49] Aurora [16:06:05] and also that the addresses looked right, but the values were weird [16:06:14] yeah [16:06:19] I accidentally deleted every fourth bit [16:09:07] so I need to spend some time digging around in here [16:09:17] it looks like there were no jobs executing -- all of the core sets are free [16:09:49] self test switch was disabled, although it appears to have passed a bunch of self-tests [16:11:25] oh, haha [16:11:37] latitude [16:11:58] the latitude (2510 and 2511) hasn't changed from before [16:12:03] but it now makes sense to me [16:12:07] this AGC was used in Houston [16:12:11] 29.5°N [16:12:17] not Cape Kennedy, 28.5°N [16:12:21] hahahahaha [16:12:23] yes [16:12:25] amazing! [16:12:30] and the AZIMUTH is probably similar [16:12:38] not aligned to one of the pads [16:13:43] can azimuth be turned into longitude easily? [16:14:50] no, that's just how the launchpad would be oriented [16:14:54] usually 90° [16:15:02] LC-34 is 100° [16:15:11] LC-39 and LC-37 are all directly east [16:15:18] not sure Aurora has a longitude setting [16:15:50] hmmmm [16:16:23] the latitude would be on the southern end of the MSC [16:16:33] indy91, I discovered why when you do an EVA on the moon, the CO2 builds up and when you repress the cabin you get a CO2 light. during EVA, we currently leave the LMP in the suit & exhaling CO2 in the suit circuit. With the suit fans not functioning, the CO2 levels go up [16:16:46] is 29.5 the full precision stored? [16:16:54] ah, it's the LMP fault [16:17:01] I have already found a solution, and implemented something for it [16:17:01] 29.553223° [16:17:51] I did that by hand, which was totally unnecessary, the conversion is simple [16:18:41] hahahaha [16:19:11] 29.5532226563° [16:20:04] Sunburst37 already has LC-37 specific coordinates [16:20:23] but retains the old LATITUDE variable which is used for testing [16:20:30] :D [16:20:44] so I'm not sure we can figure out which building the AGC was used in, haha [16:20:57] haha that's what I'm trying to do [16:21:15] draw latitude line, look for buildings on that line [16:21:18] it's double precision and they didn't use the lower half [16:21:27] so probably not very precise [16:21:39] hmm [16:21:49] what's the precision with just one word? [16:21:53] 0.02° [16:22:01] ah [16:24:10] latitude is probably necessary for some gyro torquing stuff [16:24:11] indy91, I have added an extra state for the PAMFD: PLSS. When in PLSS, the astronaut is not yet in EVA, but he is not in cabin, nor in suit [16:24:30] keeping the attitude in launch alignment [16:24:34] that doesn't require longitude [16:24:54] probably all that was store [16:24:57] sure, Alex [16:25:01] so the CDR has to be in PLSS to start his EVA, and the LMP can stay in PLSS for the whole thing [16:26:34] right [16:28:10] also no polar axis vector or launch state vector stored [16:28:17] that would also have given the initial position away [16:29:24] hmm [16:29:30] but there might be a prelaunch matrix [16:29:38] PRELMTRX [16:33:05] that's interesting [16:33:57] although the scaling would have to be weird for this to work [16:35:01] yeah, doesn't really work [16:35:07] boo [16:35:10] Aurora12 and Sunburst37 have the same address for this [16:35:23] seems like it probably didn't move then [16:36:49] yeah, I would think so [16:38:39] it's overlayed with TRANSM1 [16:39:21] oh, I forgot to ask, that first scenario you sent, MCC-7 -- you said it needed a TIG input but I don't think I got the number from you [16:39:21] so might be overwritten [16:39:27] right [16:39:31] I think 292h GET [16:39:53] yep [16:40:02] which is about 3 hours before reentry [16:40:26] perfect [16:40:26] thanks [16:40:33] I'm going to run that right now :D [16:40:40] great [16:42:22] and N60 can stay all zeros [16:42:31] and that's all for inputs [16:43:20] so just start P37? [16:43:42] yep [16:43:54] okay, noun 33 says +223h, 20m, 36.8s [16:44:02] yeah, that's some old TIG [16:44:07] which it often stores [16:44:11] probably MCC-6 or something [16:44:18] just overwrite it with the 292h [16:44:21] gotcha [16:44:49] after PRO on the N60 it calculates the conic solution [16:44:56] so without the coasting integration routine [16:45:05] so close to the Earth it's already rather accurate [16:45:18] for the results, N61 is splashdown coordinates [16:45:30] N39 is time between TIG and entry interface [16:45:46] and the update N60 has entry interface velocity and angle [16:45:49] updated* [16:46:09] a PRO on that N60 starts the precision calculation, which takes a bit longer [16:47:30] okay so put in all zeros for N60 [16:47:40] er no, I can just pro [16:47:41] right [16:47:42] yes, for me it already was [16:47:44] okay it's thinking [16:48:15] noun 61, +01300, -14121 [16:48:35] noun 39, +00002, +00058, +05817 [16:48:47] noun 60, +36088, -00647 [16:49:03] hmm, I have different values in N61 [16:49:09] but the same for N39 and N60 [16:49:21] I may have screwed up, one second, let me try again [16:50:07] could the clock time be off by the way you are loading the erasable state? [16:50:21] hmmmmmmm [16:50:24] good be [16:50:32] *could [16:50:37] I get 26.34°N and 159.4°W in N61 [16:50:48] I think I am using the same scenario, haha [16:51:11] anyway, on the second N60 you just PRO again and it will do some more thinking [16:51:17] and show N61, N39 and N60 again [16:51:27] that time the precision solution [16:51:27] wow that's quite different [16:51:43] no, I got the same answer the second time [16:51:46] inertially it's the same (N39 and N60), but N61 depends on timing [16:51:51] exact same [16:51:53] and the Earths rotation and all [16:52:08] what's the clock time? [16:52:27] and you loaded Artemis? [16:52:32] V16N65 shows +290, +32, +4196 [16:52:37] yeah, Artemis [16:52:59] yeah, scenario starts at about 290:30 [16:53:37] +00292E +00000E +00000E [16:53:38] maybe I'm doing it wrong [16:53:44] after a V25E right? [16:53:45] in N33 [16:53:50] V25E +00292E +00000E +00000E [16:53:54] right [16:54:10] strange [16:55:14] same answer third time [16:55:33] try P21 [16:55:40] I do halt the computer, load memory, and then inject a hardware restart to make it start up cleanly [16:55:41] V37E 21E PRO PRO [16:55:42] okay [16:56:01] okay it's thinking in P21 [16:56:11] that will give the current lat, lng and alt [16:56:13] noun 6 verb 43 [16:56:28] -00825, +13344, +39083 [16:56:49] after how much time has passed since loading? [16:56:50] roughly [16:57:09] a couple of minutes? I can do it immediately after a load [16:57:44] or we can use a common time [16:57:51] 291h [16:57:57] in N34 [16:58:00] could switch settings have anything to do with it? [16:58:18] probably not [16:59:01] okay, so rerunning P21 with 291h in N34 [16:59:32] -00793, +12777, +11474 [16:59:40] I'm pretty sure I gave you Alex's Apollo 15 scenario [16:59:44] I also have a NO ATT light because of lack of IMU [17:00:23] right [17:00:32] shouldn't be a problem [17:00:47] so I get the exact same altitude [17:00:51] R3 [17:00:55] but lat and long are different [17:01:12] so it's something with the planetary inertial orientation subroutine [17:01:38] I can't imagine what [17:02:13] huh [17:02:37] with the altitude exactly identical the state vector should be intact [17:04:38] very little for this routine is in erasable [17:04:40] very strange [17:07:43] I'll have to try to reproduce this on the FPGA [17:07:48] yeah [17:08:03] could be a copy & paste error of some sort [17:08:06] by you or me [17:09:03] yep [17:09:14] oh [17:09:16] hmm [17:09:26] well, a different TEPHEM would also be possible [17:10:14] the only erasables involved that I can think of are EMEM1706 to 1716 [17:10:49] okay I can take a look at them via the monitor after I've loaded the state [17:10:50] one sec [17:12:29] I doubt it thinks you are in the lunar SOI, then the altitude would be wrong, haha [17:14:03] this is E3,1706, right? [17:14:16] yep [17:15:40] 00000, 32251, 26320, 00000, 03325, 00000, 00001, 37777, 37777 [17:15:41] I think [17:16:41] oh [17:16:46] does the pad file you give me omit zeros? [17:16:57] yes [17:17:01] oh [17:17:05] ooh [17:17:11] I'm only writing to the memory locations specified haha [17:17:27] okay so let me zero memory and *then* load your scenario [17:17:32] those you just gave me are correct [17:17:43] but the issue could be elsewhere then [17:18:25] it would have to be some value it is using that is nominally 0 [17:18:26] hmm [17:18:37] P37 is thinking again [17:18:59] our save files are like 12000+ lines long, you think I am saving 0s? :D [17:19:05] okay now I get the same answer as you :D [17:19:09] awesome [17:19:19] +02634, -15940 in noun 61 [17:19:25] hooray, not something wrong with the AGC, lol [17:19:31] hooray, water landing [17:19:50] and then PRO to N60 again [17:19:52] after that is N81 [17:19:56] that's the DV vector [17:20:02] 4 ft/s [17:20:08] yep [17:20:14] +00040, +00000, -00001 [17:20:17] same [17:20:24] and then the PRO starts the precision calculation [17:20:31] alright, it's thinking [17:20:51] indy91, PR sent [17:20:59] about a minute of thinking [17:21:04] btw, a full AGC draws a steady ~2.3 amps at 28 volts [17:21:19] okay it's done thinking [17:21:27] noun 61, +02637, -15939 [17:21:28] almost the same N61 again [17:21:33] yeah [17:21:47] N39 also almost the same as before [17:21:56] N60, too [17:22:00] DV a bit different [17:22:02] 4.4 ft/s [17:22:08] yep [17:22:12] +00044, +00000, -00002 [17:22:20] and then a unique P37 feature [17:22:27] it modifies the TIG based on engine used [17:22:30] option code 7 [17:22:34] 1 is SPS, 2 is RCS [17:22:43] this would be RCS [17:22:58] V22E 2E on the 04 06 [17:23:13] okay done [17:23:17] it's now reading 2 [17:23:37] PRO [17:23:48] N33 is the TIG modified by burntime/2 [17:23:56] noun 33, +00291, +00059, +04958 [17:24:07] yeah, so it moved the TIG 10 seconds earlier [17:24:10] for a 20 second total burn [17:24:18] it needs that feature for long P37 calculated burns [17:24:25] nice [17:24:29] because finite burns become different from impulsive ones [17:24:40] another PRO [17:24:48] the familiar V16 N45 with a countdown [17:24:55] and then PRO ends P37 [17:25:05] awesome! :D [17:25:16] and then just back to POO I presume? [17:25:20] yeah [17:25:26] hooray [17:25:35] that's neat [17:25:36] thanks! [17:25:41] I still want to figure out which 0 was responsible for through the latitude/longitude off so much :D [17:25:44] no problem [17:25:47] hehehe [17:25:54] good to see an actual AGC be able to do this still [17:26:38] :D [17:28:17] AlexB_88, merged [17:28:34] thanks [17:31:54] so now, when the procedures indicates that the crew don their PLSS, you can do that in the PAMFD [17:32:31] great [17:32:44] takes a bit less time than the real thing I guess [17:32:51] and that sets that crew member out of the cabin & suit circuit [17:33:04] very basic implementation :D [17:33:59] of course, you can only go in PLSS when the LM is in contact with the surface [17:36:58] not sure Rusty Schweickart likes that [17:37:31] back in a bit [17:46:17] ah, right the Apollo 9 EVA [18:04:38] which was entirely tethered I think, so having a PLSS floating around there would also no really be right [18:13:31] was it independent from the LM ECS? [18:16:11] yeah, the LMP disconnected [18:16:14] https://thespacecollective.com/image/cache/data/apollo-9-lm-eva-checklist-cdr-copy.pdf [18:18:41] ah thanks [18:24:20] hmm, uplinks don't complete when I use 0.1 seconds between uplinked number [18:24:27] just stops in between [18:24:40] in the middle of an uplink I mean [18:25:42] not very convenient lol [18:25:44] I think I only made receiving slower [18:25:46] not sending [18:26:45] I think Ill just make PLSS available all the time, in case we end up implementing Apollo 9 LM EVA one day [18:27:05] ok [18:32:16] I'll make the PCM listen at the previous speed (0.005s between sending data), but for the special code and the uplinking MFDs I'll make it 0.1 seconds [18:32:31] that seems to make it work right [18:32:40] special code for the MCC* [18:32:57] and when it's just listening it's the via TCP/IP [18:36:31] updates pushed [18:37:29] ECS light flickering, slower uplinks, "ground computer" command Saturn venting on/off, timing of T-10s countdown sound fixed [18:37:45] great [18:38:51] and before the weekend I was working on some more IU stuff [18:39:25] just moving some code that is currently in the EDS class in its own class, the control distributor [18:39:38] the EDS does more than emergency detection, but not that much more :D [18:41:40] all based on the Saturn Systems Handbook [18:44:01] should also lead to being able to remove some more unrealistic LVDC code for liftoff [12:00:21] hey [12:10:37] hey Niklas [12:31:28] still rewiring the IU a bit [12:41:49] oh, and the Apollo 11 real-time website is online: https://apolloinrealtime.org/11/ [12:42:15] has all the mission control audio as well, cleaned up and all. Much nicer way to continue listening to the RETRO loop [12:46:19] cool [13:10:58] that site is just fantastic [13:12:02] yeah, even better than the Apollo 17 one which has existed for a few years [13:12:10] right [13:22:21] I've only tested the changes with the Saturn V so far, let's see how badly I have broken the Saturn IB :D [13:24:23] oh, maybe not at all [13:24:42] btw I am looking through the saturn systems timestep code, it seems to use a tFactor which seems to modify the simdt in some way...could that explain the more stable ECS in the CSM? [13:25:23] in SystemsInternalTimestep(double simdt) [13:25:31] oh cool [13:28:27] yes it limits the timestep length and calls those functions multiple times per simulation timestep, if the step becomes too long [13:28:37] but I think it only applies to very high time acceleration [13:31:18] oh the LEM already has it [13:31:54] I think it only does something if a timestep becomes longer than 50 seconds [13:31:58] so 3000x [13:33:30] right [13:34:08] I wonder what else contributes to CSM ECS stability [13:35:38] well whenever I did a small change to the CSM ECS I made it less stable [13:36:11] so it's probably well adjusted, and also it takes some shortcuts with realism in the right places [13:36:33] or rather, it handles some stuff in code and not by adding more Systems SDK systems [13:37:28] right [13:37:54] is there a way to debug the LM to see exactly what system is causing the most of the instability? [13:38:59] we have many debug lines set up for that [13:39:26] but it's not easy to figure out from that what tank or so is responsible [13:40:03] yeah those debug lines are monstrous lol [13:40:06] with my one small stability fix I did I just chose one subsystems and followed the flow [13:40:15] I started with the descent O2 tank [13:40:37] and went through each manifold tank and looked at pressures, valve sizes etc. [13:41:59] I guess just increasing valve sizes can help [13:42:28] larger valves make things less stable usually [13:42:45] also note that valve size is saved in the scenario [13:42:53] because they can be modified by code [13:43:02] so that's not just in the config [13:43:52] large valves plus small tanks can cause a significant part of the tank content to be removed by a flow [13:44:09] on the next timestep it recovers due to pressure differential [13:44:24] so you get an unstable pressure in that tank [13:44:42] and probably in a whole loop, if the tank is part of one [13:45:12] so smaller valves then [13:46:00] usually [13:46:14] valves too small can cause that the system behavior isn't right [13:46:27] right [13:51:16] but back to the timestep thing, isnt there a way we could make something for slower time acceleration as well? Like say if I have 30x then the system will run 30x slower? [13:52:55] we could probably to force a specific maximum step length [13:53:10] would of course increase CPU usage at higher time accelerations [13:53:40] well the vAGC doesnt work above 50x anyway [13:55:01] well doesnt work "well" lol [14:00:50] right [14:37:58] in SystemsInternalTimestep() [14:38:10] I tried double tFactor2 = (simdt / oapiGetTimeAcceleration()); [14:38:12] and [14:38:16] Panelsdk.SimpleTimestep(tFactor2); [14:38:50] its stable like a rock at 30x, but I think theres more to it then just that [14:39:34] probably all the consumers are also reduced by 30x [14:45:11] if you are doing a shorter timestep then you have to call the timesteps multiple times per step [14:45:20] that's what the loop is for [14:47:31] right [14:51:22] oh [14:51:22] hmm [14:51:31] the logic there is actually different than what I thought [14:51:39] it's quite clever [14:51:59] so from a timestep length 0 to 0.5 seconds (that would be 30x) everything is normaly [14:52:01] normal* [14:52:20] from 0.5 to 50 seconds timestep length it has a fixed steplength of 0.5 seconds [14:52:46] and does as many cycles as necessary, per one timestep [14:53:16] and at super high time accelerations, beyond 50 seconds timestep length, it lets the steplength go up again [14:53:24] probably not to totally freeze up the simulation [14:53:29] to not* [14:53:54] it limits it to 100 cycles per timestep [14:54:06] very clever system [14:54:30] yeah [14:57:08] I think with the current stability of the LM ECS more than 2-5x time acceleration is already bad [14:57:20] what would you want to limit that to? [14:58:57] anything more then 1x probably [15:01:22] double mintFactor = __max(simdt / 10.0, 0.02); [15:01:38] that would limit it to 0.02s step length [15:01:46] and maximum of 10 cycles per timestep [15:02:00] not sure how many still would give a good frame rate [15:02:15] hmm [15:02:16] no [15:02:37] this would make the step length go up again at 12x already [15:03:28] we might want to try and have it at the very stable setting with up to 50x I guess [15:03:51] I only use 50x for deep space coasting really [15:04:01] 10x usually in low orbits [15:04:17] and even if the step length goes up again, it only does so gradually [15:04:25] its stable [15:04:40] with double mintFactor = __max(simdt / 10.0, 0.02); [15:04:50] at 30x [15:05:20] 30x will have the step length of 0.05 seconds with this [15:05:29] which is only 3x time acceleration equivalent [15:05:50] right [15:06:08] at 10x this is still at the 1x time acceleration setting [15:06:17] it goes up at 12x again [15:06:24] with constant 10 cycles per timestep [15:06:50] you were saying this could affect frame rate at higher time accel? [15:07:19] it will, but it won't get worse at even higher time accel [15:07:46] with this setting it starts doing the 10 cycles per timestep at 12x [15:08:22] so the performance loss from this is constant at 12x and more [15:13:04] simdt / 10.0, 0.02 makes its stable up to 50x [15:13:18] fps stays the same [15:19:04] So at 100x the fps goes down dramatically, but maybe we can make it switch to a more fps friendly setting at 50x or so? [15:19:33] and at least have a stable ECS up to 50x [15:20:05] 100x fps loss is probably the emulators [15:20:38] I pulled the cbs [15:20:45] hmm [15:20:52] oh the CSM [15:20:58] forgot that one [15:21:00] yeah [15:21:07] and the AEA [15:21:25] pretty sure the performance of the ECS shouldn't go further down [15:21:34] above 12x in this case [15:21:35] yep nevermind [15:21:39] same fps at 100x [15:22:29] this seems to be a good solution, what do you think? [15:22:51] if weaker CPUs don't hate it too much, yes [15:23:02] LM panel is rather CPU friendly [15:23:03] Ill test it on my laptop [15:23:08] yeah [15:23:45] we dont need it in the CSM anyway [15:23:51] not yet at least [15:24:09] unless Ryan comes back and models every last pipe and tube in the CSM :D [15:24:49] yes [15:25:05] and there is this one uni project that seeks to replace the whole LM ECS [15:26:00] but if this makes it stable for now, that is great [15:26:23] yeah [15:26:29] whats this uni project? [15:27:44] I forgot his name, but there is a person from Australia who has been here a few times who wants to make our LM ECS an uni project [15:27:56] replace it with a better system and all [15:28:06] oh right [15:28:17] more of a long term project, probably only really gets started later this year [15:28:21] not relevant for NASSP 8 [15:28:23] speaking of [15:28:44] I'd say a stable LM ECS warrants that NASSP goes Beta [15:28:51] agreed [15:29:17] I'll do that change once I have merged my IU changes. This time actually, I promise [15:31:11] just a Saturn takeover change needs to be done for that still [15:34:05] haha no rush on the change [15:34:39] Ill do some testing with the timestep change and Ill PR in the next hour or so [15:34:50] we have been talking about it for a while [15:35:22] I think this Beta period should be shorter then NASSP 7 [15:35:49] basically a few tweaks and checklist fixes, documentation [15:36:12] I dont know if we want to go through with the XRsound change or not [15:36:18] maybe that can wait for NASSP 9 [15:43:05] yeah [15:43:30] there is a bit more instability at 50x versus 30x, very minor though [15:43:33] "we might want to try and have it at the very stable setting with up to 50x I guess" [15:43:46] did you mean I can make it stable up to 50x? [15:47:47] with more performance loss, yes [15:48:41] it is limited at 10 cycles per timestep [15:48:43] right [15:48:57] so 50x would have the equivalent of 5x time acceleration right now [15:49:03] we can make that even smaller [15:49:11] by doing e.g. up to 20 cycles [15:49:30] CSM has 100 [15:49:39] but at larger time accelerations [15:51:28] mintFactor = __max(simdt / 20.0, 0.02); [15:51:31] for example [15:52:06] this would have normal steps from 0 to 1.2x [15:52:26] from 1.2x to 24x it would be limited to 0.02 seconds steps, as before [15:52:37] beyond 24x it has 20 cycles per second [15:53:08] so 50x would have the equivalent of 2.5x, not 5x [15:54:14] rock solid at 50x [15:54:38] no notable fps difference, Ill check higher time accel [15:56:30] still good fps at 1000x [15:56:52] ECS is unstable by then of course [15:57:21] byt I think if we can make very stable at 50x then thats good [15:57:30] yeah [15:57:57] even 100x is stablish [15:58:48] 100x is the 50x from before [16:07:07] now trying 30.0, 0.02 [16:07:15] fps is still pretty good [16:07:29] only drops slightly at 100x and up [16:08:23] we don't need to overdo it, haha [16:08:35] I'd say we go 20 cycle per timestep max [16:09:19] ok [16:09:42] Ill test this on my laptop now [16:16:32] btw I get an master alarm go of at each scenario start in the LM, maybe theres something in the CWEA thats not save/loading correctly [16:17:27] theres no new caution light coming on at scenario start that would explain it, so it must be one thats already on [16:18:54] hmm [16:19:10] I had pushed the fix for the flickering ECS light [16:19:32] https://github.com/dseagrav/NASSP/issues/491 [16:19:37] which I thought was causing this [16:23:23] so I don't think that is the cause [16:23:26] I wouldn't know how [16:23:55] I can debug it [16:24:03] I will* [16:31:36] 20 cycles works good on my laptop [16:36:47] I think it is related to the ECS light though, my Apollo 14 pre-EVA 2 scenario has the H2O sep light not yet on, and there is no MA at scenario start, then it come on with the suit fans winding down and the ECS light comes on, then when saving reloading the MA comes on at scenario start due to the ECS light being on [16:40:21] in your not-so-old Apollo 10 scenario I don't get a master alarm at scenario start [16:40:30] maybe only something in old scenarios [16:41:59] oh, I think I know [16:42:08] if in a scenario the ECS light was on [16:42:17] then the master alarm gets re-triggered [16:42:23] due to the counter [16:42:26] which is not saved [16:42:41] how does the CSM CWS handle this... [16:43:18] so saving/loading a scenario with a ECS light on will trigger another master alarm [16:49:29] oh and on some instances, when RCS is firing and I change panels, the RCS TCA flags come on [16:49:51] I know you mad a counter for that, maybe it can count a bit more? [16:49:56] made* [16:52:26] oh that was just for time accel [16:53:07] oh wait, no [16:55:00] ok so it detects if its in time acceleration, if so bypasses the logic. Not much you can do for just switching panels I guess [17:08:03] indy91, PR sent [17:09:24] it's both a counter and a timer [17:10:04] the time is 0.08 seconds, so if a really long timestep happens during panel switching... [17:10:36] although I might be able to delay it a timestep [17:14:12] AlexB_88, it's actually the same for the FC lights, which also have a counter [17:14:20] I pull the SCE breaker, FC lights on [17:14:24] master alarm pushed [17:14:26] save/loading [17:14:29] master alarm on again [17:14:52] I don't really want to add saving for that counter... [17:15:22] PR merged [17:15:42] thanks [17:15:56] yeah makes sense [17:16:06] is the ECS light usually on during EVA? [17:16:10] yes [17:16:16] hmm [17:16:19] H20 separater [17:16:22] might be worth it then [17:17:03] maybe slightly less annoying :D [17:17:27] we won't need a counter for any other light [17:17:53] do we even need the counter at all now that we forced the LM ECS to be stable? [17:18:40] panel changes are still a thing for the ECS [17:18:42] hmm I was wondering that exactly [17:18:56] all the numbers I were talking about were for 60fps [17:19:16] yeah it might still be worth it for panel switching [17:19:35] I'll add saving for the counter then [17:21:21] so at 50x, if you have lower fps, you might still get an auto-transfer of the glycol pumps. I wonder if a counter would work now for those as the system is probably stable enough to not get near the count limit at 50x [17:21:50] all this during EVA I mean, when you have the auto-transfer cb closed [17:22:19] sure [17:22:27] that one definitely won't need saving/loading :D [17:24:11] yeah [17:24:21] morning! [17:24:27] hey Mike [17:24:52] what's up? [17:25:38] hey [17:25:45] yo [17:26:01] AGC is en route home [17:26:03] gave the LM ECS to be stable in time accel [17:26:07] got* [17:26:35] well, mostly from Niklas's advice :D [17:27:21] Did you geto to fixing the AGC? [17:27:23] nice :D [17:27:32] stable ECS is awesome [17:27:36] by sacrificing performance [17:27:38] but still [17:27:40] heh [17:27:43] better than before [17:28:01] no, we didn't fix the newly failed diode, but we did keep the current switch module here with us so we can further excavate it and replace the part [17:28:09] ah [17:28:50] we also kept the erasable memory module to make sure it doesn't receive any further unnecessary shock from being handled on the flight [17:31:05] right [17:31:22] but now I am really wanting to figure out if our Aurora 12 is closer to Aurora 85 or Aurora 88 [17:31:42] ND-1021402 has some differing procedures between the two and I may ask for help figuring out if our Aurora has the changes or not [17:38:44] unfortunately it seems that the most obvious change is in a piece of code written by a very lazy person [17:39:03] who has left no comments and simply labeled things "BBBB", "CCCC", "DDDD", "EEEE", etc. [17:39:21] which makes it very not obvious :P [17:41:02] very lazy [17:42:03] I expect Shakespeare quotes, at the very least, in commented code [17:43:05] anyways the difference is that when running system tests in Aurora 85, you use V21N01E 02550E 00041E to skip the RR check, and in Aurora 88 you instead use 00042 [17:43:41] so they have apparently added a test and what you're modifying there is changing the index of the test you're on [17:44:07] how do we so much about those Auroras? [17:44:13] the one we have is 12, right? [17:44:20] 12 with an asterisk [17:44:21] but it's a weird numbering system [17:44:23] yes [17:44:39] our Aurora 12 was based off of either 85 or 88 [17:44:52] it's not mainline aurora; they should have renamed it but they didn't [17:45:16] ah, right, so the erasable state was from an earlier version, not a later one [17:45:37] they just took some revision of Aurora, reset its revision to 0, and started adding extremely hacky code to it for DAP testing [17:46:00] right [17:46:02] the erasable state was from some real revision of Aurora [17:46:07] either 85 or 88 [17:46:18] and we have test procedures for those [17:46:22] yeah [17:46:29] drawings seem to indicate 85 [17:47:08] *but* since the phase tables are one off from Aurora 12, and we can show that Aurora 12 was based off of Aurora 85, then it must have been Aurora 88 [17:47:21] (assuming the DAP group didn't screw with other things in bank 2) [17:47:44] so we got it pretty closely tracked down [17:47:58] https://archive.org/stream/acelectroniclmma00acel_0#page/n412/mode/1up/search/aurora [17:48:05] not that much due to my knowledge, if it was a flight version I would have been more of a help [17:48:44] haha well, you almost had it identified as Aurora even in spite of the very corrupted data I sent you :P [17:48:55] yes, haha [17:49:03] the addresses felt right :D [17:50:21] hehehe [17:52:55] so I guess if you got everything repaired and in good condition next time then the AGC is ready to do whatever you want to do with it for the anniversary [17:53:01] yep! [17:53:16] so now we just need to figure out what that is [17:53:23] haha [17:59:06] will need some help setting it up probably [17:59:25] but I think we could probably get reasonably far pretty quickly with direct counter writes [18:00:02] yeah [18:00:12] I can also probably detect writes to output counters too, as opposed to changes from count cycles, but that'll need a little bit more fiddling [18:00:22] NASSP to FPGA should work by using the data stream from out SetInputChannel function [18:00:57] channels are a lot harder, heh [18:01:08] ah [18:01:15] channels 30 through 33 are very difficult for the monitor to deal with [18:01:20] because I can only inject 1's, not 0's [18:01:24] and with those channels being inverted... [18:01:33] for the most part I can't affect them [18:01:55] writing to counters is unfortunately a bit spread out [18:02:02] sometimes the memory is just manipulated directly [18:03:32] but we take it step by step and reroute things, haha [18:03:52] :D [18:04:27] you know [18:04:38] okay this is very hacky [18:05:01] so was getting the abort switch ignored [18:05:02] but there is a way that I can inject channel values [18:05:30] I can have the monitor wait for the AGC to execute an instruction that reads in a channel [18:05:56] and then immediately after it sees that instruction, inserts its own memory cycle that changes the value of A to be what we want [18:06:01] then all you would need a buffer with data written from NASSP [18:06:05] is* [18:06:17] although it will be tricky to properly handle ROR, RXOR, RAND [18:06:41] so I probably need to grab what's in A immediately before the channel access [18:06:56] so I can perform my own operation against the NASSP channel data and then inject that into A... [18:07:31] and make sure that that reliably happens every time before the AGC gets a chance to execute another instruction that might use that data [18:08:36] sounds hacky [18:08:52] it's the only way if we want to bypass the input pins [18:09:47] there's going to be a lot of verilog work here but the more I think about it the more I think it's doable [18:10:19] why do we need to bypass the input pins? Is there no way to have a buffer of data that gets written to by outside and accessed by the AGC? [18:10:45] would that need more of a hardware solution than software? [18:11:02] there isn't any particular need, and would be the easier way to do it with the real AGC [18:11:16] but I only have 10 pins left on my AGC board after breaking out all of the monitor stuff [18:11:33] I suppose I could make a little expander board that does SPI [18:11:41] and just a bunch of GPIO buffers [18:12:19] but between design, layout, and manufacture I think the verilog solution for the FPGA will probably be more expedient [18:12:32] unless it turns out to be a massive complicated rabbit hole, which it might [18:13:11] back in a bit [18:13:20] plus the board on the other side that actually changes the pin states to match what NASSP wants needs to be designed too [18:14:57] right [19:38:01] huh [19:38:17] when was AS-503 formally redesignated for the lunar flyby? [19:39:39] there's an interesting memo from August 27, 1968 [19:39:41] USE OF LTA-8 ( LUNAR MODULE TEST ARTICLE 8 ) FOR AS-503 ( APOLLO SATURN 503 ) [19:41:47] there was a meeting on this on August 9 [19:42:13] August 19, Assignment of Saturn V 503, CSM 103, and LM-3 to Mission D was canceled. [19:42:18] Saturn V 503 would be prepared to carry CSM 103 and LTA (LM test article)-B on a manned CSM-only mission to be designated the C prime mission. [19:43:03] huh [19:43:06] Memo, Low to Joseph N. Kotanchik, MSC, "Use of LTA-B for AS-503," Aug. 27, 1968. [19:43:15] maybe a typo? [19:43:16] oh [19:43:19] 8 vs. B [19:43:22] yeah that could be [19:43:36] that would make more sense [12:00:42] hey [12:02:15] hey Alex [12:02:32] testing some launches [12:02:43] to verify all is working with the IU [12:03:05] nice [12:03:08] I got an Apollo 7 engine failure right at liftoff, I first thought I had broken the LV engine lights [12:03:20] but then I checked, yep, engine is actually off [12:03:29] and I almost made it to orbit before running out of fuel [12:03:41] forgot to turn off failures? [12:03:49] I wanted to test failures [12:03:58] ah right [12:04:05] but the number 1 engine light was on directly after liftoff [12:04:18] so I thought I maybe had broken it, changed some stuff about those lights [12:04:26] I actually had to do a Mode III abort then [12:04:32] so close to making orbit :D [12:04:52] probably the first time I didn't do a Mode III abort deliberately [12:05:04] aaaaand then I forgot I had to fly half lift, not full lift [12:05:10] so I landed in Africa anyway [12:05:28] oops lol [12:05:56] one difference you might notice is that when you get a LV guid light during first stage flight, then the LV rate light will also be on [12:06:19] not sure why really, secondary cue for such a failure maybe [12:06:42] interesting [12:06:45] maybe you have read that that light should be on in some checklists [12:07:12] it being on as well is linked to the auto overrate abort being still enabled [12:07:33] when it gets disabled by the IU or the switch then that light will be off, unless you get an actual overrate condition of course [12:07:43] in the saturn1b right? [12:07:55] any Saturn [12:08:01] ah [12:08:27] Apollo 15 launch checklist for example: "If LV GUID & LV RATE lts-on" [12:08:43] then LV GUID - CMC [12:09:18] so an LV GUID light alone would not b enough to go to CMC control? [12:09:27] be* [12:09:28] hmm [12:09:54] it's just a secondary cue for the same thing, I think [12:10:01] so yes, if you only get LV GUID, also go to CMC [12:10:09] ah ok [12:10:13] that will be the case after 2 minutes, when the auto aborts are disabled [12:10:31] right [12:10:37] the checklist said this early in first stage flight [12:10:41] at 2 minutes it says [12:10:47] "LV RATE lt disabled as IU failure cue" [12:11:49] the logic for that has also changed. Previously I had a bad solution that makes sure the LVDC doesn't disable S/C control of the Saturn again in a guidance failure case [12:12:04] when TB6 starts the LVDC normally takes back control [12:12:23] but that is now working correctly [12:12:49] I moved the relay for that from FCC to EDS, so old scenario won't let you take over normal Saturn control in TB5 and TB7 [12:12:52] scenarios* [12:14:07] ok [12:15:36] so now if you have a guidance failure, whats the difference? TB6 still leaves you control? [12:16:45] it's not really different from before, but I had implemented extra logic in IU and FCC to prevent this [12:17:17] now there is some relay logic in the EDS for that [12:18:05] I have done bunch of changes, but mainly they are changing stuff from" implementation derived from how it should behave" to "implementation derived from Systems Handbook and actual relay logic" [12:18:19] not that many changes in behavior noticable [12:18:39] ah ok makes sense [12:19:28] I like the latter :) [12:21:16] the changes definitely help if we ever run actual LVDC code [12:21:23] or want to simulate more GSE stuff [12:22:17] I guess the IU & LVDC is as real as it gest now, much better then what it used to be in NASSP 7, LVDC being an "add-on" that wasnt really well integrated [12:23:40] yeah, I would think so [12:24:04] especially the IU has progressed a lot in the last year or two [12:24:22] yeah [12:25:46] I have also implemented the logic for S-IC engine cant, but that isn't done yet [12:26:05] the outer S-IC engines are angled a bit to the outside so that they point closer to the CoG [12:26:20] that would have helped with engine failures [12:27:27] that is commanded by the IU for a certain time after liftoff to before S-IC cutoff [12:27:35] by the FCC to be precise [12:46:58] right now, I am testing LM ECS temperature stability [12:47:46] on my save Apollo 10 scenario after LM activation, with the new timestep fix the whole ECS is pretty stable obviously, except for the suit/cabin temperature [12:48:42] yeah, I wonder what causes the temperature instability [12:49:02] I have a theory that the whole TLC at 30x with the old timestep might have screwed stuff up in the ECS [12:49:43] beacuse if I activate a fresh LM from SIVB separation, the temps look much more stable, even with time accel [12:51:17] any NaNs? [12:53:04] nope [12:53:46] right now I am flying a whole TLC with the new timestep, then Ill activate the LM [12:54:38] is the suit loop a near vacuum during TLC? [12:55:07] hmm not sure [12:55:22] I can check [12:56:14] I guess we need to check each heat source that could be responsible [12:56:21] in what way is it unstable? [12:56:39] its pressurized [12:57:11] well in my Apollo 10 LM scenarios in lunar orbit, the temperatures fluctuate a lot [12:57:16] even without time accel [12:57:55] whats your experience with this, do you find it unstable as well? [13:00:59] yes, but very different from glyocl pressure [13:01:14] going up and down a higher range over longer periods [13:01:37] I find that if you take out the crew, the temps go down quite a bit [13:02:22] yeah, that too [13:02:31] and it also fairly easily goes beyond 100°F [13:02:36] under certain conditions [13:02:36] yeah [13:02:43] crew in cabin [13:02:59] if theyre in the suit its not as bad [13:03:24] yep [13:03:40] but I wonder if the crew is giving off to much heat [13:05:50] could be [13:06:02] although I think we use some number from the LM Systems Handbook for that [13:06:14] about the glycol auto transfer [13:06:24] you wanted a counter for that as well? [13:07:03] sure [13:07:40] I have tested one locally already, and it helps for when switching panels [13:07:56] ok [13:08:05] how many counts? [13:08:10] I put 20 [13:08:13] yeah [13:08:22] I had 10 first for the ECS light, but it wasn't always enough [13:08:31] 20 is good [13:11:00] I'll back back in the evening, cya! [15:24:35] .tell indy91, so I did TLC, and LOI and activated the LM. Temperatures a pretty stable (no fluctuations like I was having before) I strongly believe this was caused by the old timestep & time accel that must of screwed with something in the ECS during TLC and caused the temps to be erratic after LM activation [15:25:20] .tell indy91, temperature are still not quite correct (too low when crew in suit & too high when crew in cabin) but they are not erratic like they were before for me [15:26:37] .tell indy91 the suit temp rotary seems to do very little in terms of controlling the temps, I wonder if its even wired? [16:57:11] good evening [16:57:20] morning! [16:57:37] hey [16:57:49] AlexB_88, Ryan said something about that rotary [16:58:16] something about the wrong system cooling/heating the counterpart [16:58:49] I think it had to do with creating more heat loads and not directly having radiators connected to tanks [17:06:41] oh interesting [17:07:41] like, allowing more flow with the suit temp rotary is having the opposite effect as desired [17:10:06] ok, ECS light counter is saved [17:10:18] and glycol pump auto transfer counter implemented [17:10:59] how did you have that set up? Directly with GlycolAutoTransferRelay? [17:12:29] if (PressureSwitch == false && DPSensor < 3.0 / PSI) [17:12:30] { [17:12:30] if (GlycolPumpCount < 20) GlycolPumpCount++; [17:12:31] } [17:12:32] else [17:12:32] { [17:12:33] GlycolPumpCount = 0; [17:12:34] } [17:12:57] and then the if (GlycolPumpCount >= 20) in the following code [17:13:15] it worked but it may not of been the best way to do it [17:13:19] I just put it in the if/else if of the GlycolAutoTransferRelay logic [17:13:29] and added another else which also reset the counter [17:13:50] ... I think that should work [17:14:54] yeah [17:15:29] I put it later in the logic [17:15:36] so pressure switch is still set as normal [17:15:43] which probably only telemetry cares about [17:15:54] right [17:15:55] so about the suit temp rotary, increasing the flow will not give more control for cooling/heating I guess [17:17:05] yeah, I think it has little effect right now and basically the wrong one. [17:17:15] Just based on what I remember from what Ryan told me [17:18:59] "glycol pump failure auto transfer relay", the German in me likes this a lot, although we would make this one word [17:19:00] ok [17:21:31] the ECS components CG location are still the same as the CSM [17:22:08] yeah [17:22:16] I have just played with that actually, the components in there rough positions, ascent/descent stage [17:22:33] didnt change much [17:23:12] I think the length of the position vector can have an influence on how much the tank is affected by thermal radiation [17:24:31] other than that, the LM points many parts of itself at the sun [17:25:56] so say <0.0 -1.0 0.0> thats means the component is 1 meter down? [17:27:15] yeah [17:27:39] the positional aspect definitely works, I've tested it with the CSM [17:27:44] SM RCS [17:28:01] right [17:28:04] pointing one quad at the sun for many hours triggers the CWS [17:28:14] freezing is not as much of a problem, there are heaters [17:28:19] and it takes much longer [17:28:39] but we have a mechanic where the propellant can freeze and the quad stops working [17:28:53] Ill have to put the correct positions for the LM quads, RR, S-band etc [17:29:12] mechanism* [17:29:20] probably as simple as finding the mesh coordinates, then adding the offset we use in code [17:30:13] of course it shouldn't always scale, further from origin doesn't always means it gets more affected by the sun [17:30:31] so the direction of the vector should be right, length of it, not necessarily [17:31:45] but position is just the position of it with respect to the center of the vessel, right? what do you mean by length of the vector? [17:32:17] or that it doesnt have to be at its actual CG location but just toward the right direction from center? [17:32:38] yeah, that [17:32:43] ah ok [17:33:52] in our thermal engine it does a dot product between a normalized sun direction vector and the position vector [17:34:07] position of a thermal system (e.g. a tank) [17:34:36] so the length of the position vector is basically a multiplicator [17:38:24] tank isolation is a different factor though [17:38:49] so maybe the position should just be the real position in spacecraft coordinates as close as possible [17:38:58] and any fine tuning should be done with isolation [17:41:00] updates pushed [17:41:07] which includes the IU overhaul [17:44:01] I like how the most notable change of that is that there are two lights on during a IU guidance failure, not one. Lots of work for that! [17:45:10] haha [17:45:34] the next IU system still missing is the auxiliary power distributor, mainly for switching power between ground and onboard though [17:45:48] not super relevant yet [17:46:05] oh, and I am still missing a few EDS timers [17:47:02] next time I get a guidance failure Ill pause and take a minute to think of all the work it took to get those 2 light :D [17:47:03] they are backup for switch selector events, something about the Saturn being safe even if the IU switch selector fails [17:47:25] it's almost all IU systems involved [17:47:36] it starts at the EDS (I put the IU failure code there) and ends with the EDS [17:47:50] but in between it goes to LV IMU, LVDA, LVDC and back to the EDS :D [17:53:28] oh, I used your old Apollo 15 launch scenario for testing that failure [17:53:52] it was from before we added CSM RCS being usable [17:54:00] so the S-IC propellant tank was empty [17:54:09] which did cause a launch abort with the new ML logic [17:54:29] not sure where all that exhaust came from with an empty tank :D [17:54:54] I guess that should be based on actual thruster thrust [17:55:12] not thrust level, which can be above 0 even with an empty tank, I think [17:55:13] hmm [17:55:15] maybe [17:57:07] back in a bit [20:05:35] I think ill study the LM ECS in detail to figure out a way to have more control over temps [20:06:23] but the timestep change really seems to help stability, especially new scenarios where the ECS has not run with time accel in the old timestep [20:06:52] haven't tried it yet, but I am sure it does [20:12:56] hmm I get an auto abort on my Apollo 11 guidance fail scenario [20:13:12] oh lol [20:13:17] stupid me [20:13:22] ENGINEFAIL 1 2 25 [20:13:23] ENGINEFAIL 1 3 25 [20:13:23] ENGINEFAIL 1 5 25 [20:13:36] I was testing some stuff a few weeks ago [20:13:47] yes, two engine auto abort applies to more than two engines as well :D [20:14:14] yeah [20:14:31] I think in that case I was trying to force it to do an LV rates abort [20:14:39] ah, interesting [20:14:47] I should test that a bit more [20:14:47] with the 2 engine out switch off of course [20:14:51] haven't had one really [20:15:04] giving the S-IC engines a maximum gimbal rate would also help [20:15:09] but the Saturn 5 can keep control even on 2 engines in seams [20:15:10] they only have a maximum gimbal angle [20:15:26] it come back down of course, but doesnt lose control [20:15:31] things might be different with a gimbal speed limit [20:16:07] and maybe a more realistic aerodynamics simulation [20:17:43] gimbal speed limit can easily be implemented, an instant gimbal acceleration should be sufficient [20:17:54] yeah id like to see that [20:18:26] well, I guess if we have the actual data on it [20:19:39] we have [20:22:40] 5°/s for the F-1 engine [20:22:59] which is pretty quick [20:23:00] SPS can only do 2°/s [20:23:20] https://twitter.com/DJSnM/status/1140682066759077888 [20:23:52] cooler than your FPGA [20:24:01] in both meanings :D [20:26:33] hehehehe [20:26:37] I'm not sure I have seen this picture [20:26:53] I just now saw it too. Scott took it when he was visiting us [20:27:00] ah, nice [20:27:22] the AGC itself is quite cool -- the hot things are my FPGA monitor and the rope simulators! [20:27:42] the cool spot below the "X" on the tray A cover (from this orientation) is very annoying [20:27:54] that's where the thermistor is that I can use to calculate temperature in my monitor [20:28:01] turns out it's in one of the coolest spots, heh [20:28:11] sounds like cheating [20:28:16] haha yeah [20:29:13] so I guess we can expect a nice video on this from Scott? [20:33:53] indy91, does the SPS already have the 2°/s implemented? [20:34:08] yep, he recorded some stuff [20:34:43] AlexB_88, yes [20:34:51] I had a much more realistic system in place [20:34:57] but it wasn't numerically stable [20:35:17] https://en.wikipedia.org/wiki/Stiff_equation [20:35:19] I hate them [20:35:38] haha [20:37:56] I think I might use the SPS code to put the 5°/s in the S1C, just for testing [20:38:31] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.msg23306#msg23306 [20:38:51] this is what could have been, haha [20:39:11] I wonder if that would work better now with the timestep mod of yesterday [20:39:57] that only runs SystemTimesteps, but yeah, if we force a maximum step length on it [20:40:44] if you want to try it with the S-IC, then you need to set commanded angles in F1Engine::SetThrusterDir [20:41:01] and the actual gimbal angle change like the SPS [20:41:52] ok [20:43:24] btw this more realistic system, did it give any noticeable effect to the operator that isnt present now? [20:43:36] for the SPS? [20:43:38] yeah [20:43:51] you get some interesting jiggling of the needles on the GPI [20:43:57] other than that, not much [20:44:03] ah [20:44:12] 2°/s constant speed pretty much gives the same stability and all [20:44:13] still cool though, haha [20:44:26] maybe something for NASSP 9 [20:44:31] yeah, I quite liked it. Based on the GSOP section 6, so the simulator they had at MIT [20:44:54] the digital simulator [20:46:31] and for the DPS it's 0.2°/s constant, where constant is even more realistic [20:47:31] the LGC assumes that rate when it's driving the DPS gimbals during a V48 gimbal drive test [20:55:26] hmm, having trouble finding where the speed limiting code actually is in the SPS [20:55:29] LMR = 0.15*DEG;? [20:56:15] hmm [20:56:20] I thought it was 2°/s [20:56:28] but that would be 0.15 radians per second [20:56:45] but yeah, that is the rate I think [20:57:07] thats like 8.5 degrees per sec [20:57:16] yeah [20:59:15] so there would need to be a separate timestep for the F1 engine gimbal I guess [20:59:52] gimbal timestep, yes, called from the F-1 timestep [21:00:19] right [21:02:04] 0.15 rad/sec gimbal rate limit according to GSOP section 6 [21:02:11] not sure what I remembered with 2°/s... [21:10:51] and then we expect some people who worked on Apollo to remember anything :D [21:11:40] hehehehe [21:12:11] yeah imagine somebody asking you nitty gritty NASSP details in 50 years :P [21:12:24] my brain isnt working fast enough right now to implement this speed limit thing in the S1C :D [21:12:27] Ill probably try again tomorrow [21:16:51] I can do it tomorrow as well, I've used this implementation in a bunch of places [21:16:54] HGA as well [21:17:14] good night! [03:48:31] hey @AlexB_88 [04:13:56] hey [04:14:01] off to bed, night! [12:16:57] hey [12:18:00] hey Alex [12:18:26] There is a fun bug currently [12:18:55] the S-IC two adjacent engines out cutoff is usually enabled just before IECO [12:19:15] but the timing of that is based on Apollo 8, which does the IECO 10 seconds early [12:19:34] so I got a case, two engine failures, and then the S-IC cuts off the other four outer engines [12:19:38] but not the center one [12:19:51] so the center one keeps on burning for another ten seconds, all alone .D [12:19:52] :D [12:20:15] cuts of all four outer* [12:20:17] off [12:21:01] so for Apollo 9 and later I need to fix the flight sequence programs in late TB1, so that the timing works again [12:21:18] I have good sources, just never updated that part [12:32:35] interesting, must be weird to see just the center one burning [12:34:12] yeah, more often it's the other way around [12:35:22] oh, and giving the F-1 engines a gimbal speed limit doesn't do much [12:35:40] it's more the moments of inertia (as usual) and aerodynamics I guess [12:36:30] right [12:36:54] it probably gives it more realistic feel during manual flight (saturn takeover) [12:39:23] yeah, I think I'll still use the implementation [12:39:41] and about the moments of inertia, I have started researching and as usual our values are off [12:40:11] by factor 3 for pitch and yaw and factor 20 for roll [12:40:20] oh wow [12:40:53] we use no airfoil for the Saturn, but the simple model Orbiter provides instead [12:41:00] so no transonic effects and nothing [12:42:52] we should definitely remedy that [12:43:08] yes [12:43:15] FCC deals with it just fine [12:43:37] roll rate needle is jittering more at liftoff [12:43:52] the new PMIs? [12:43:57] yeah [12:44:24] there also are parameters for aerodynamic resistance against an attitude rate [12:44:31] probably also too high [12:44:40] but that's even more difficult to find data on [12:44:53] for the CM it's also too high, the rolling reentry technique doesn't work [12:44:59] rotation gets stopped too quickly [12:50:14] Ive been looking at the LM ECS all night yesterday, but I still dont really have an idea of how to fix the temps. [12:50:37] One thing I can add I think is radiators for the DPS and RCS propellant temp indicators [12:52:39] I guess we have something similar to that in the CSM already [12:53:48] yeah [12:55:51] oh and I gave most of the components new cg positions [12:56:29] quads/RR/LR/IMU case and SBand steerable should be correct now positionally [12:56:37] great [12:56:52] I have tested it it with the sun and it works good [14:00:35] indy91, MainFuelTempInd::QueryValue() in lemswitches.cpp directly returns 70 [14:00:48] yes [14:00:52] as a placeholder [14:00:53] but shouldnt that be getting it from the scea? [14:00:58] oh [14:00:59] hmm [14:01:13] a few displays don't actually [14:01:15] the scea already calls the gettemp function [14:01:16] let me check [14:01:33] in some weird cases the SCEA is only used for telemetry [14:02:01] is that RCS? [14:02:14] DPS [14:02:33] ah [14:02:37] but RCS might be the same [14:03:50] it should be from the SCEA [14:04:13] depending on switch setting [14:04:24] ok [14:05:00] I can try and figure out how to do it, TempMonitorInd::QueryValue() has an example of values from the scea [14:05:19] SCERA-1, SA-9, channels 1 and 2 [14:05:34] and 3 for the APS I guess [14:05:55] ok [14:06:19] and similarly for the oxidizer [14:15:01] so I got a radiator defined for one the tanks and working in sim [14:15:24] full scale low, I guess now I have to figure out how to keep it in the green band [14:16:03] Do those have heaters? I looked through the AOH but havent found anything yet [14:17:50] RCS? [14:18:44] DPS [14:19:34] I'm not seeing any heaters in the Systems Handbook [14:21:11] The supercritical helium initially passes through the first loop of the two-pass fuel/helium [14:21:12] heat exchanger. [14:21:39] 2.3-6 in the AOH [14:21:55] right [14:22:16] not sure how much that affects the tank temperatures though [14:22:58] right [14:23:36] I wonder how it was kept from freexing [14:23:40] freezing* [14:24:27] with some difficulty [14:47:41] haha, I had a bug in the S-IC engine gimbal speed limit, so I never actually tested it [14:47:58] the gimbal command was used for the thrust direction, not the actual gimbal position [14:50:32] so let's try this double engine failure at Max Q again... [14:52:18] haha [14:53:22] I also implemented the 2° engine cant now [14:53:30] actually, it seems more stable than before [14:53:48] I think the instant gimbal angle change is a bit of a overreaction [14:54:27] I'll also try it without the engine cant [14:55:59] with the current aerodynamics the high Q probably stabilizes it rather than destabilizing [14:58:49] right [14:59:01] return lem->scera1.GetVoltage(9, 3); that probably still needs scaling? [14:59:02] without the cant it has a large 2.5°/s peak in yaw [14:59:17] yes [14:59:27] but notice that scaling is done at two points [14:59:35] the SCEA will return 0-5V [14:59:53] but the meter also has a scaling in its definition [15:00:35] MainFuelTempInd.Register(PSH,"MainFuelTempInd",40,200,2); [15:00:56] in a few cases you can change this to 0-5V and don't need any additional scaling in the function [15:02:25] 40 to 200? [15:02:28] shouldn't it be 100? [15:03:24] yes [15:05:20] so 0V = 20°F, 5V = 120°F [15:05:26] display is scaled 40 to 100°F [15:05:39] 1V = 40°F [15:05:50] and 4V = 100°F [15:05:53] so that is pretty easy [15:06:00] no scaling in the function [15:06:03] and [15:06:11] MainFuelTempInd.Register(PSH,"MainFuelTempInd",1,4,2) [15:06:44] so just that change? [15:06:59] I think so [15:07:01] and the return lem->scera1.GetVoltage(9, 3); [15:07:06] right [15:07:23] channel 3 for the APS [15:08:23] so it just needs a check on the switch to decide which SCEA channel [15:09:17] already done [15:10:23] hmm its still showing full scale low [15:10:54] should show 70 [15:11:11] the functions in the DPS and APS are unchanged still? [15:11:46] I have some code that reads the new radiator I added, but for now thats commented and just has the old return 70 [15:12:13] in DPSPropellantSource::GetOxidizerTank1BulkTempF() [15:12:14] etc [15:13:02] trying to get the SCEA to properly read 70 from those functions [15:15:05] MainOxidizerTempInd needs the same change to 1V and 4V min/max [15:16:03] I'm gone for a bit, if you haven't figured it out by then, then I'll also try to read this from the SCEA. Sometimes these meters are a bit tricky [15:16:13] ok [15:42:39] I get the same issue :D [15:42:47] what am I overlooking... [15:43:03] ah [15:43:03] DoDrawSwitch [15:44:14] needs the scaling [15:47:30] ok [15:47:50] 115-((int)((v-40)*1.7)) [15:47:56] both functions have that [15:47:57] thanks [15:48:15] you are thanking me too early :P [15:48:26] haha [15:48:27] and it probably should rather be (to scale 1-4V) [15:48:35] 115-((int)((v-1)*34)) [15:48:42] ok Ill test that [15:49:58] don't copy & paste the whole line though [15:50:25] the oapiBlt has different coordinates for the fuel vs. oxid meter [15:56:09] hmm, not having much luck [15:56:29] this is what I have: [15:56:30] oapiBlt(drawSurface, NeedleSurface, 149, 115 - ((int)((v - 1) * 34)), 7, 0, 7, 7, SURF_PREDEF_CK); [15:56:44] in MainOxidizerTempInd::DoDrawSwitch [16:00:38] ok, testing this, too [16:00:43] I just did the math before [16:00:53] also not working here [16:00:56] weird [16:02:16] ah, haha [16:02:21] wait for a bit [16:03:28] the needle has a maximum speed [16:03:30] in this case [16:03:31] 2 [16:03:36] also in the register function [16:03:52] I think that numbers means how long it takes from the min to the max setting [16:04:03] anyway, the previous (saved in the scenario) number is 70 [16:04:27] and from value 4 to value 1 it takes two seconds [16:04:37] so it takes like half a minute to normalize [16:04:52] I put a debug string in DoDrawSwitch [16:05:28] and when I loaded a scenario it started counting down from 70 [16:05:31] at 2 per second [16:05:46] after a bit the needle appeared and are now at 70°F [16:06:10] the main advantage of using voltage and not temperature is that one conversion less is needed [16:07:05] disadvantage is that it's not very clear in the math which temperature there currently is. Well, and issues with old scenarios like this I guess. [16:07:50] where the conversion to volts was confusing I had often left it in the old unit. But with 1V min and 4V max I thought it was easy. I thought wrong :D [16:08:43] so if you want to you can keep using temperature [16:08:58] but then the QueryValue() needs a conversion from volts to °F [16:11:27] right [16:13:37] Ive decided to abandon by plan of setting up radiators for the propellant tanks, I dont have enough knowledge about how to set up those things and I rather not end up with something half realistic [16:14:18] that's fine [16:14:26] these topics need a lot of time to get into [16:14:46] at least you discovered that the SCEA needs some more to do :D [16:15:00] but I guess the system can still be wired via the SCA, that calls the GetFuelTank1BulkTempF() etc from the DPSpropellant class and not directly in QueryValue() [16:15:05] SCEA* [16:15:28] still just returning 70 F but still [16:16:05] so Ill just put the volts to F conversion in QueryValue() [16:17:37] ok [16:17:54] Fahrenheit = 20*Volts + 20 [16:17:55] I think [16:18:09] then the change to DoDrawSwitch is not needed [16:18:24] and the Register function needs to be fixed, it had 200 as the max before [16:18:29] but it should be 100 [16:19:01] those maximum values are not used for scaling, but just the value given to DoDrawSwitch is limited [16:19:18] right [16:19:39] so 40,100,2 [16:21:09] yeah [16:22:49] return ((20 * lem->GetAPSPropellant()->GetFuelTankUllagePressurePSI()) + 20); [16:22:54] in QueryValue() [16:23:07] no lol [16:23:51] return ((20 * lem->scera1.GetVoltage(9, 4)) + 20); [16:24:03] I had it in the wrong section before lol [16:26:20] works [16:27:07] great [16:27:22] one more pair of needles going up when the SCEA is powered up [16:27:34] or not [16:27:46] the CB for that meter is probably not used until later [16:27:53] yeah [16:27:54] which is why I didn't notice this before [16:29:11] MainOxidizerPressInd still does not use SCEA, but that might be a case where its supposed to be that way I guess [16:30:03] yes [16:31:04] likely because the pressure sensor returns 0-5V on its own [16:33:30] or whatever the meter likes, those pressures are not on telemetry [16:37:52] hmm what about RCS temp, does that use SCEA in reality? [16:38:00] in NASSP it doesnt [16:38:38] it's all in the Systems Handbook [16:39:26] RCS has constant 70°F still, right? [16:39:35] looks like it should be SCEA [16:40:03] yeah [16:40:19] Ill change that too [16:40:49] LM-8 Systems Handbook page 244 [16:41:27] although I don't think all settings of the rotary actually have a temperature [16:45:10] only the PRPLNT setting has a temperature [16:45:30] and the rest should make the needles go dead? [16:45:50] morning! [16:45:55] hey Mike [16:45:55] yeah, down to 20°F [16:45:56] hey [16:46:08] what's up? [16:46:27] making the S-IC both more stable and less stable [16:46:47] hahaha [16:48:13] AlexB_88, you can make it return 0 or 20 in those cases, doesn't matter, it gets limited to 20°F by the Register function [16:48:19] so 20°F is "offscale" low [16:50:32] and the SCEA temps are from [16:50:47] SCERA-2, SA-20, channel 2 and 3, for A and B [16:51:30] scaling in QueryValue the same [17:10:42] and done [17:24:05] AUTO/MAN thrust CMD should also be SCEA I think [17:25:26] oh [17:26:06] that's correct [17:26:27] I can take a look at that, I just rescaled that stuff [17:26:34] with the DPS isp and erosion update [17:26:47] ok [17:27:24] actual thrust on the other hand is not SCEA [17:27:34] I think a few other things too, like the FDAI pitch/yaw needles [17:27:36] right [17:29:17] and quad temps [17:41:27] good morning [17:48:53] hey [17:55:30] yo [17:56:17] indy91, you might be interested in some of the drawings we got from NARA yesterday [17:56:30] lots of subsystem-level mechanization drawings [17:57:26] there's a lot of them in box 465, which isn't done processing yet, but check out the first dozen or two drawings in box 466: https://archive.org/details/apertureCardBox466Part1NARASW_images [17:59:49] ah, optics stuff [18:00:13] a bit more details than the Systems Handbook [18:00:51] thanks! [18:01:10] not just optics, there's stuff like this for most subsystems it seems like :D [18:02:39] but all MIT [18:03:38] ? [18:06:54] yeah [18:07:07] most MIT subsystems, I meant [18:07:45] right [18:08:17] i had an issue with the apollo 11 entry scenario [18:08:35] what was it? [18:08:51] when i tried the p52 the scope would not align with any stars [18:09:21] but it worked for mcc7 [18:09:48] is that your own scenario or the one that comes with NASSP? [18:09:58] nassp [18:10:18] so [18:10:19] Apollo 11 - 21 - Before MCC-7 T+191h26min [18:10:20] worked [18:10:30] but [18:10:30] Apollo 11 - 22 - Entry Preparations T+193h17min [18:10:33] had the problem? [18:10:39] I'll check [18:10:52] yes [18:10:55] we changed the optics switches which you probably noticed [18:11:00] yes [18:11:15] i did a p51 for the entry preparations and i think it might have fixed it [18:11:16] possible that the input bits to the AGC from the switches are set wrong [18:11:35] would just need switching back and forth to fix it [18:11:49] I'll try if there is an actual alignment issue there [18:11:56] or just the new switches being annoying [18:13:22] yeah, I think it is the new switches [18:13:28] the Zero switch is in Zero [18:13:48] but the AGC has angles from the sextant anyway [18:14:08] so to fix that in that old scenario you need to switch the Zero switch to off [18:14:09] then to zero [18:14:13] then wait 15 seconds [18:14:15] and then you are good [18:14:22] okay [18:14:45] the computer is basically out of sync with the sextant [18:14:49] and needs to be re-zeroed [18:15:05] you can see that with V16 N91 [18:15:13] that shows the sextant angles as the computer thinks they are [18:15:20] very non-zero in the scenario [18:17:06] during your P51 you probably moved the optics switches back and forth and that also fixed it [18:26:38] indy91: so I think today is the day (again). I'm going to get an NASSP development environment set up and start playing around with getting it to talk to my FPGA AGC [18:26:50] and then maybe fly some missions?? [18:27:04] who knows [18:27:11] haha [18:27:29] https://www.orbiter-forum.com/showthread.php?t=40351 [18:28:44] and I'm sure there will be someone here most of the time to help [18:29:17] maybe not if you are doing this in the evening in your time zone .D [18:30:06] hahaha yeah [18:30:13] I'll probably have questions tomorrow morning though :D [18:30:23] sure [18:30:39] I can come here when I wake up if that helps, haha [18:30:53] haha maybe [18:31:07] your 10pm is my 7am [18:31:09] only if you're not doing anything else, this isn't super urgent [18:33:10] well I can be here at 7am. Earlier than 6am or later than 8am would be less convenient, haha [18:33:28] but Alex wrote a good guide [18:33:34] should keep you busy for a bit [18:33:46] lots of stuff to download and set up [18:39:37] have you changed anything in the 8 scenarios? [18:39:56] yeah, lots of stuff to do [18:40:08] and I have to figure out if my monitor can be talked to on windows without a lot of pain [18:40:09] indy91, PR sent [18:40:53] astronauthen96__, no, I haven't. But I am currently flying Apollo 8 again an I'll update the set of mission scenarios then. [18:41:50] i tried the before sivb sep scenario and the sivb was maneuvering [18:42:17] i think i remember something was wrong with that [18:42:33] hmm [18:42:42] well, those scenarios are quite outdated by now [18:42:48] could be many things [18:43:24] AlexB_88, if (lem->TempPressMonRotary == 1) [18:43:35] doesn't that need a .GetState() or so? [18:44:53] and monswitch should be set to NULL in the constructors [18:46:13] adding that now [18:46:35] what is weird is my test worked without the GetState() but I guess it really needs to be there [18:48:10] well, not necessarily, there would be a way to set that up [18:48:14] I grabbed the monswitch code from an other class below it, it seems to not have anything in its constructor, but maybe it should too? [18:48:22] I'll check if that is [18:48:32] yeah, probably [18:48:41] gives a clean CTD if the init wasn't called [18:48:48] instead of undefined behavior [18:50:15] right [18:50:23] RotationalSwitch::operator int() { [18:50:23] if (position) { [18:50:24] return position->GetValue(); [18:50:24] } else { [18:50:25] return 0; [18:50:25] } [18:50:26] } [18:50:54] this makes it return GetValue(), if you just do [18:50:55] (lem->TempPressMonRotary == 1) [18:51:02] so that is indeed setup [18:51:14] overloads some operator, not sure what this is called [18:51:44] "conversion operator" apparently [18:51:51] or cast operator [18:52:17] PR amended [18:55:00] you added the GetState in LMRCSATempInd only, not in LMRCSBTempInd [18:55:13] I guess we just figured it works right both ways, but let's be consistent :D [18:56:29] where is my brain today :D [18:57:26] on the Moon maybe [18:58:23] must be [18:58:30] PR re-amended [18:58:38] or somewhere together with my first F-1 engine gimbal speed implementation [18:59:13] merged [18:59:27] thanks [18:59:52] Hows the F-1 work coming along? [19:00:24] gimballing and engine cant works fine, will push soon [19:00:33] gimballing with a speed limit [19:01:03] definitely makes an engine failure less stable [19:01:15] and the 2° engine cant makes it stable again [19:01:25] nice [19:02:11] and of course I also changed the late TB1 commands from LVDC to the stage [19:02:28] so that that weird center engine being on alone doesn't happen [19:03:11] and also added a Apollo 9 flight sequence program file, until now it used the one for Apollo 8 [19:04:07] I never had downloaded the S-IVB flight evaluation report for Apollo 9, that has the full list of commands [19:04:23] well "full", for some reason it was omitting one important step [19:04:29] I guess gimbal speed limit will be applicable to the SII and SIVB as well [19:04:37] yeah, I can check that next [19:04:47] I've been mainly focussing on IU and first stage stuff [19:05:21] So I guess the Saturn 5 will feel lighter now [19:05:53] with the reduced PMIs [19:06:09] the roll and pitch program go a bit faster now I think [19:06:27] it struggled to reach the 1°/s limit before [19:06:53] I think one of my 1st tests will be guidance failure, then flip it to CMC and right away V46 :) [19:07:14] finally trying to get a LV overrate auto abort? :D [19:07:43] I guess if I fail a couple of engines on the same side as well [19:08:34] SaturnV::SetFirstStage [19:08:34] which makes me wonder, no checklist says this, but you could get full manual control of the Saturn V in TB1 [19:08:40] SetRotDrag (_V(0.7,0.7,1.2)); [19:08:51] you could mess with those numbers to get less angular rate damping [19:09:01] yes, that works [19:09:04] say with a guidance failure, you go to CMC and the CMC steers the rocket, but you COULD go even further and hit V46 [19:09:07] V46E gives you manual [19:09:24] right [19:11:07] I forgot the procedure, so I did that once by accident during first stage flight [19:13:29] oh, before going to CMC? [19:13:38] no, CMC and V46E [19:13:43] immediately [19:13:58] I thought V46E was part of it to give CMC control [19:14:07] not for manual control [19:14:21] I don't think the boost cue card has enough numbers for first stage flight to be very usable :D [19:14:29] 30 second steps [19:14:42] I guess there is nothing in the system that prevented the real astronauts from taking full control [19:15:02] in the event of a guidance failure that is [19:15:11] yeah [19:16:00] AOH does have the V46E early [19:16:04] "if man cont req" [19:16:15] error needles not usable in manual [19:16:25] ah ok [19:16:42] right, they just display RHC deflection [19:16:52] or the breakout switches [19:17:48] yeah, will be the same as the commands to the IU [19:18:26] and whatever the CMC does internally, Saturn steering is not that simple [19:20:54] you change the scaling of those commands [19:21:09] I wonder if that works prelaunch, so that you can cause high attitude rates [19:25:28] yeah [19:25:33] back in a bit [20:07:11] night! [05:26:37] thewonderidiot still awake? [05:28:24] indy91: I am [05:28:45] but as you probably will have predicted I got distracted and haven't done NASSP things tonight [05:29:06] haha, I see [05:29:28] in my defense, it's not entirely my fault. my work decided they wanted me to give a lunchtime presentation on the AGC work on Friday, so I've been putting together a slide deck [05:30:28] my current distraction cycle is: find bug, research bug, find a bunch new features that are desirable, implement features creating new bugs [05:30:34] ah, nice [05:30:36] hehehehe [05:31:23] I know how that goes [05:31:34] but yeah, I'm putting together the full story, and am pulling out old emails and chatlogs to help tell it [05:31:38] it's fun to look back at these things [05:32:12] yeah, interesting times [05:32:14] like how the whole restoration thing more or less started from you pulling AGC pin numbers out of nowhere on me [05:32:19] good evenign [05:32:24] hey [05:32:26] evening [05:32:30] hey [05:32:48] have you seen the apollo 11 in real time site yet? [05:32:53] oh from the Systems Handbook? [05:32:57] yeah [05:32:58] yeah [05:33:01] haha [05:33:53] the real time website has cleaned up all the mission control audio, which is nice [05:34:28] was available before, but I had to turn up my speakers to near max to hear anything [05:36:10] also when i get an mcc uplink it seems to uplink slower than it did before do you know what could cause that? [05:36:21] thewonderidiot I was playing the long game, the goal was of course to run erasable data from me on a real AGC all along [05:36:48] hehehe [05:37:16] yeah, I made it slower. I found out that they uplinked data at 10 digits per second [05:37:27] half as fast as before [05:37:57] is that what it would have looked like on the real mission? [05:38:03] well, Steve told me, so I just implemented it [05:38:16] probably, yeah [05:41:07] there is a giant uplink on Apollo 7, I wonder if that would even be finished in one tracking station pass now [05:58:35] cya later! [12:19:50] hey [12:26:35] found better numbers for the S-IC engine out pitch freeze, I think [12:36:17] hey Niklas [12:36:31] nice [12:37:29] from an Apollo 9 EDS document [12:37:41] it has the configuration for Apollo 8 and a suggested config for Apollo 9 [12:37:54] which I am not sure was implemented, the list of flight program changes doesn't have it [12:38:07] it wouldn't be a huge change from 8 to 9 [12:38:17] but the difference to what we are using would be significant [12:38:32] as we suspected, much longer freeze time for early failures [12:38:41] right [12:38:43] 60 seconds instead of 36 [12:39:04] It must help to have enough fuel for TLI, after an early failure [12:41:19] for sure [12:41:31] I am tempted to implement the Apollo 9 version [12:41:41] in shape it looks closer to what we currently use [12:41:47] in any case I just have to change default numbers [12:41:48] makes sense [12:41:50] the scheme is the same [12:42:36] the numbers we use is in a graph call "reduced loads chi-freeze schedule" [12:42:47] so it probably is rather for reduced loads, not maximize performance [12:53:07] although there is one change in the scheme, the pitch program freezes are never implemented before T+38s [12:54:04] so with an early launch it wouldn't go straight for a 60 seconds :D [12:54:09] early failure* [12:55:11] straight up [13:02:07] hmm, so it doesn't go for 60 seconds until after T+38? [13:03:06] yeah, engine failure at e.g. 5 seconds [13:03:11] normal pitch program up to 38 seconds [13:03:17] pitch freeze for 60 seconds from there on [13:03:19] then it continues [13:03:24] right [13:04:04] probably to ensure the rocket doesn't stay over land for too long [13:04:04] that is different from what we currently have [13:04:08] yeah [13:04:43] the parameters are saved in the scenario, so if you want to test it when I have commited it you need to use a new scenario, or delete a bunch of lines in the scenario [13:04:58] ok [13:05:27] that will come with the other new stuff (pmi's gimbal etc) I guess? [13:06:33] yeah [13:06:42] although I am not sure yet I am committing the PMI change [13:07:29] I want more testing, the roll needle can go a bit crazy at liftoff, which I hope doesn't cause a worse IU state vector or so [13:07:53] ok, now I have to test a few engine failures at specific times :D [13:09:25] oh, and I also had found better FCC gains for the Saturn V [13:09:39] we use nearly all the right ones already in pitch and yaw [13:09:47] but in roll they are smaller [13:10:13] the new PMI for the roll axis I am using is still conservative, so not as much of a change as it could be [13:10:24] and with those roll gains it would do a super slow roll program [13:11:23] right [13:14:38] Orbiter uses mass normalized PMI [13:14:53] but a rocket stage that is mainly fuel apparently doesn't change its roll axis PMI much [13:15:00] nearly constant [13:15:37] so if I mass normalize that again then I get about 2.5 at liftoff, 5.8 at cutoff [13:15:45] so changes a lot during launch [13:16:02] of course we could make this variable, recalculate the PMI during flight [13:16:46] 2.5 at liftoff, 5.8 at cutoff, and we currently use 116.60 [13:16:51] just laughably off [13:21:08] wow [13:27:26] oh, and with an engine failure so early the unrealistic aerodynamics are really becoming obvious [13:28:01] the Saturn is drifting around, nothing bringing it back to following the flight path [13:28:22] it just keeps any attitude it wants despite the aerodynamics which should do bad things to it [13:30:33] huge angle of attack [13:31:39] ah, right [13:34:24] but it's definitely giving the Saturn a high altitude to continue flying [13:35:53] oh, random failure on the S-II, haha [13:36:04] didn't even increase the failure rate [13:36:58] 1 in 128 is the chance of that, for each engine, so 5 in 128 I guess [13:37:27] I wonder if it still makes orbit [13:37:36] definitely will be very late [13:44:21] SECO will be as late as 16 seconds, haha [13:44:24] minutes [13:45:52] 15:50 [13:45:54] good orbit [13:46:02] spent 60% of the S-IVB propellant [14:02:17] nice [14:02:44] I guess a bit shy of whats needed for TLI, but then again you had 2 separate failures right? [14:03:33] on my end Im playing around with the RTE targeting in RTCC MFD [14:03:38] quite versatile [14:04:43] I purposely put myself in a weird 60x4000 nm lunar orbit, not aligned with the earth-moon line [14:06:01] and using the RTE to see how I can get myself back home from here, search option works well, discrete option works at any point along that orbit. In some cases very high DV, 6000+ but quite normal I think [14:06:06] yeah, one scheduled S-IC failure at 5 seconds, and then one halfway through S-II flight [14:06:36] nice [14:06:54] search option gave me a sort of "fly-by" tupe burn a few hours before pericynthion with a 390 NM pc height [14:06:58] it's based on the actual RTCC document, we shouldn't expect nothing less [14:07:04] yep [14:07:06] should* [14:07:20] although what I didn't implement yet is some direct/fly-by logic [14:07:31] you can actually specify what you want with the real processor [14:07:45] for us it should always give a flyby [14:07:50] right [14:09:48] I tried using discrete TIG option to force it to fly home from a specific point in that orbit, gives me a 6000+ fps solution, I assumed that would be direct, or maybe its still a fly-by [14:11:26] well if you were in lunar orbit it's more of a TEI [14:11:37] even from a weird lunar orbit [14:11:52] your case sounds like one of the LOI abort modes [14:13:22] yeah [14:15:42] search option might also be breaking down a bit [14:15:55] I think it's meant for a nearly circular orbit [14:16:08] in your case the TEI would also be at perilune [14:16:12] always* [14:20:11] pushed all my updates, except the PMI change [14:20:48] back in a bit [14:36:01] one topic that is probably a bit too difficult to do right now is Saturn tank pressures displayed in the CSM [14:36:11] those are pressures, not fuel level or so [14:36:24] they should be quite constant while the engine is running [14:36:41] and in the Saturn IB it currently displays S-IB propellant data [14:36:55] it can't do that, in the Saturn IB CSMs that only displays S-IVB pressures [14:38:48] oh really [14:40:27] I had never even questioned that, but does say pressures not quantity [14:40:44] it's like the abort light, you just never question it :D [14:40:53] yeah [14:41:02] trying your updates now btw [14:41:09] not until you are researching it and then you have a "wait a minute" moment [14:41:20] haha [14:41:30] or the auto position of the tower jettison switches [14:41:43] I guess they stay constant and then drop off near staging [14:41:48] yeah [14:41:59] for a S-IVB restart mission it's quite complicated [14:42:03] goes down after shutdown [14:42:22] and then up and down and up again, based on which valves are open etc. [14:43:09] what I can do is move the current calculations in the stage classes, so that at least it is located in the right place [14:43:18] and then later any pressure simulation can be done there [14:43:26] yeah [14:45:10] https://i.imgur.com/GTaIdgn.png [14:45:22] Apollo 11, LH-2 pressure, before TLI and later [14:46:38] about 15 psi before launch (until pre-pressurization), then 30 psi until basically S-IVB cutoff [14:46:48] then slow decay to 20 psi [14:47:00] and then that until the pic above [14:48:37] the two things you need to monitor is that the pressure doesn't go above 50 psi [14:48:55] and that the pressure differential between LH2 and LOX isn't too high [14:53:13] right [14:53:40] about the new pitch freeze values, what lines should I delete in old scenarios? [14:53:52] many, haha [14:54:07] let's see... [14:54:23] LVDC_B_11 [14:54:25] LVDC_B_12 [14:54:26] LVDC_B_21 [14:54:28] LVDC_B_22 [14:54:33] LVDC_t_2 [14:54:34] LVDC_t_3 [14:54:35] LVDC_t_4 [14:54:37] LVDC_t_5 [14:54:47] that should do it [14:54:55] ok thanks [14:55:11] I guess I can also implement a better scheme for the Saturn IB [14:55:23] that is using the Saturn V numbers right now, haha [14:55:48] in that case I can use the EDD [14:56:15] yeah [14:57:41] oh and just so I can test, do you have those PMIs you came up with? [14:59:22] SetPMI(_V(440.0, 440.0, 5.875)); [14:59:42] and I'm also currently experimenting with [14:59:43] SetRotDrag(_V(0.7, 0.7, 0.1)); [14:59:58] be have 1.2 for roll, definitely too high [15:00:15] 0.7 is what the Shuttle SRB uses in the default Atlantis [15:00:21] for pitch/yaw [15:00:25] and the 0.1 as well [15:03:43] thanks [15:05:28] just flying Apollo 9 launch, engine 3 failure at 15 seconds [15:07:06] oh I was curious, do the CMC polynomials have engine failure modes? [15:08:47] I don't think so [15:09:08] also doesn't have a way to detect engine failures [15:10:09] right [15:10:30] so it was probably enough to abort if you had guidance failure + engine failure [15:13:04] good morning [15:13:15] I guess you could try to do it manually then [15:13:17] hey [15:13:41] is there any way i could change the uplink speed back without switching builds? [15:14:28] you could change the code and rebuild [15:14:40] 50% fuel left in SIVB at insertion [15:14:41] is it not working right? Or is it just annoyingly slow now? :D [15:14:48] its just annoying [15:16:04] are you building NASSP yourself or are downloading the builds? [15:16:12] downloading the builds [15:17:29] just use time accel 10x [15:17:31] i can see the files you changed for 1448but i cant find them in the orbitersdk folder [15:17:35] during the uplink [15:18:18] yeah, that should work [15:18:30] Ive tried it and doesnt seem to cause issues [15:18:32] you can't change it without building the NASSP solution with Visual Studio yourself [15:21:11] do you think you could tell me how to do that or would it take too long to explain? [15:22:24] that is quite complicated [15:23:02] you need Visual Studio 2017 [15:23:24] and then basically these steps: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864.0 [15:23:43] hmm, or not [15:24:05] the NASSP release also have a "Source Code" variant [15:24:15] so you would only need to download Visual Studio 2017 and that [15:24:25] https://github.com/dseagrav/NASSP/releases/tag/NASSP-V8.0-Alpha-Orbiter2016-1452 [15:24:28] like that zip file [15:26:45] Visual Studio community? [15:27:03] yeah [15:30:02] 2017 [15:30:38] I think 2019 is already released, but we haven't switched to that yet [15:33:52] I definetly like the handling better with the new PMIs, with engine failure it seems more quick to assume the pitch freeze and then leave it [15:36:49] yeah [15:38:17] I guess it did have a bit more needle movement at ignition, but not anything that I would think thats unrealistic. SV accuracy is good [15:38:53] yeah [15:39:10] try it with the actual PMI in the roll axis at ignition [15:39:19] then you see the needle dancing [15:40:41] isn that in the SetPMI above? [15:40:48] that's the value at cutoff [15:40:56] about 5 [15:41:07] I used 5.875, I think based on a AS-501 number [15:41:25] for Apollo 8 I calculate [15:41:50] 5 at cutoff [15:41:56] ah ok [15:42:20] 1.43 at ignition [15:42:33] the not-mass normalized number is almost a constant [15:42:39] so the mass normalize value changes a lot [15:42:44] which is what we have to use for orbit [15:42:58] so about 3.3 is average [15:46:37] oh yeah 1.43 cause some jitters [15:47:22] we could probably just use the cutoff PMI for roll [15:47:41] better then 116 :p [15:49:12] yeah [15:51:19] the averave PMI value and the smaller number in SetRotDrag would probably also work with the FCC gain I found [15:53:23] its funny, in my head I would of thought at cut-off the PMI would be lower (lighter weight) [15:54:32] yes, the total usually is [15:54:59] but mass-normalized you have all the mass in the center in a full stage [15:55:28] and all the mass away from the center (the structure of the stage) in an empty stage [15:56:34] I guess if your stage is almost exclusively "light" propellant in the center, then it doesn't do much for the roll moment of inertia [15:57:08] in the SM there is a lot of other stuff than SPS propellant [15:57:23] so there the total moments of inertia go down [15:57:29] and mass normalized only goes up a bit [16:00:06] right, I guess its a very complex thing [16:06:24] so i just changed the files with VS2017 do you know what i do next [16:07:25] rebuild the solution [16:07:35] in release mode [16:15:34] indy91, I guess the DPS thrust commanded position always indicates 10% when in auto [16:15:51] with the SCEA unpowered [16:16:14] I think it's a meter internal-bias [16:16:31] so yes [16:16:34] ok [16:16:45] and in man it goes to 0 if unpowered [16:17:15] yep [16:17:41] I guess that it is at 10% even with the SCEA and DECA unpowered is new [16:18:03] but I think it is correct [16:18:29] in the Systems Handbook there is 10% bias wiring [16:18:41] going from common voltage of the meter back to itself [16:18:58] and is active with thrust control in auto [16:19:42] makes sense [16:20:16] the meter is now directly showing automatic throttle command [16:20:36] so not summed with manual command yet [16:20:52] so it needs that bias in the meter, not before [16:23:59] right [16:25:52] how do i get in release mode? [16:26:50] at the top there should be a small drop down window where it probably says "Debug" [16:26:54] I have a question about the LM systems handbook: section 9-IV at the end, page 285 and later, there is "telemetered & displayed parameters" The indicators on that list that have the "SCEA location" not dashed, are those meaning not only telemetered but also wired to the display? [16:27:46] LM-8 [16:29:06] oh maybe if they have the associated "PAM no" than its not wired from SCEA to display [16:29:42] and just used for telemetry [16:29:43] everything on telemetry has a PAM location [16:29:54] oh [16:30:09] ... [16:30:11] I think [16:30:18] not everything needs the SCEA [16:30:36] some measurements are on more than one SCEA channel [16:30:45] because they are used for multiple purposes in the LM [16:30:57] sometimes it is telemetry, display and something for the CWEA [16:31:28] but also, not everything on the SCEA has a display [16:31:53] like AC BUS FREQ [16:32:39] everything on telemetry that is not a discrete has a PAM location. I think that is how it works [16:33:48] that list is not very useful to determine of a disply in the LM should get its signal from the SCEA [16:33:51] if* [16:34:36] right [16:35:04] in the schematics there would be a SC-1 or SC-2 between display and sensor [16:35:09] that is a good way determine it [16:36:18] ah [16:37:21] and I have been quite thorough I think (I hope), so I doubt there is much left to do with that [16:38:06] even SCEA to PCM is mostly complete [16:40:59] yeah [16:41:03] looks pretty good [16:41:25] I think the quad temps are SCEA based on the RCS schematic [16:42:40] morning! [16:42:44] yes, already are [16:42:46] hey Mike [16:42:54] what's up? [16:43:19] made the S-IC engine failure logic in the LVDC better [16:43:27] fun :D [16:43:47] yeah, previously it left us at a rather low altitude at burnout [16:43:54] IGM didn't like that as much [16:44:25] hey Mike [16:44:31] hey [16:45:27] indy91, ah yes you're right. I keep forgetting middle of the display is full scale low for the quads [16:45:51] pretty weird [16:47:09] hmm [16:49:17] ah yeah [16:49:28] there is the separate scale to the right of the mter [16:49:57] and it doesn't really go below that [16:50:04] yeah [16:52:10] it should be at the low end of the scale at 0V [16:52:11] -60°F [16:52:22] thats a bit below the middle [16:54:20] yeah, should be all right [16:56:53] maybe [17:05:40] hmm [17:06:23] the scaling of the quad temps in the SCEA has changed [17:10:10] in one place it says -60° to 260° [17:10:14] in another 20° to 200° [17:35:40] 20° lowest setting is probably not right [17:36:04] that would indeed cause it to be in the middle of the display [19:07:33] cya [11:46:27] hey [11:50:07] hey [11:50:58] you probably seen this but https://www.youtube.com/watch?v=ip5d7LSTb7Q [11:51:03] pretty interesting [11:51:29] yep, I am subscribed to Marc's channel [11:51:57] of course we know how that story progresses, but still very interesting to see [11:53:21] I'm moving the LV tank pressure stuff in the stage classes [11:53:42] but it will work as before, except S-IB tank pressures in the Saturn IB [11:53:48] that will be removed [11:55:44] great [12:00:15] would be fun to get that realistic [12:00:46] S-II fuel pressure for example, should be quite noticable how it goes up from 11 psi to almost 40 fps from T-187 to T-30 [12:00:54] psi* [12:01:00] I am writing fps too often, haha [12:05:29] well to be fair if it went from 11 psi to 40 fps it would be quite noticeable :D [12:09:19] pressure to velocity increase, still sounds like a rocket stage :D [12:23:36] definitely [12:47:18] so during a regulator check in the A12 LM activation checklist, you just dumped the cabin until the master alarm and then step 4 says "as soon as possible: PRESS REG A - CLOSE" and then "CABIN warning Lt - OFF, Cabin Repress Stops" [12:48:55] what I am wondering is does the cabin light out, repress stop happen right when you go PRESS REG A - CLOSE, or is it just saying that when the pressure gets up to the green band the cabin light will go out and repress will stop (as expected) [12:51:47] the latter I think [12:52:20] the CABIN light only depends on what the repress valve does [12:52:32] the light is on when it is auto repressing [12:53:19] although [12:53:33] if it is allowed to repress also depends on the press reg switch setting [12:53:45] repress is disabled in egress [12:54:05] I guess the wording in the checklist is a bit confusing, its like if it says it should happen when you go press reg a - close [12:54:53] are you in egress before? [12:55:26] in any case, switch to close would rather cause the cabin light to be on [12:55:27] not off [12:55:37] after the auto repress is done the light will go out [12:56:30] yes, cabin gas return - egress [12:56:58] yeah and thats how it is in the sim [12:57:38] cabin gas return in egress is irrelevant [12:57:48] pressure regulators in egress I meant [12:58:04] that inhibits auto repress [12:58:42] press reg b was in egress [12:59:09] I think one of them in egress would already prevent auto repress [13:00:18] which doesn't really agree with the checklist, does it? [13:01:31] well in the checklist (and what I did) said to put press reg B in egress and press reg A to close, that does not stop the repress though [13:01:51] in the sim [13:02:00] hmm, ok [13:02:04] but the checklist seems to say that it should [13:02:43] but even thats a bit confusing because it may just be saying that it stops repressing once it gets to the green range (not because of switching the press reg a to close) [13:03:31] AOH says [13:04:01] "AUTO mode is disabled if PRESS REG A and PRESS REG B valves are set to EGRESS or if one valve is set to EGRESS and then other valve is set to CLOSE." [13:05:58] if (cabinRepressCB->IsPowered() && (pressRegulatorASwitch->GetState() != 0 || pressRegulatorBSwitch->GetState() != 0)) [13:06:06] and in code this allows cabin repress [13:06:33] which means that only both regulators in EGRESS prevents auto repress [13:09:07] oh [13:09:11] that was changed at some point [13:09:39] https://github.com/dseagrav/NASSP/commit/a1eff9392d6af9d6d3ed949622854b42ac3ff3b5#diff-249d3afbb3832d9572a26905bed940f9 [13:11:16] https://vanbeersweb.nl/irclogs/%23nassp/2018/03/2018-03-01-20:55_Log.log [13:11:21] search for repress there [13:11:35] sounds like we talked a bunch about this in March last year [13:16:30] yeah [13:16:38] sounds like that needs a slight change [13:19:55] actually, no [13:20:02] I think we changed it to this for a reason [13:20:09] not entirely sure what that was [13:20:24] but the way we have it set up agrees with the Apollo 12 procedure [13:20:57] yeah [13:21:28] well. just that it doesnt agree with the AOH quote above, it still represses in that case [13:23:02] yeah [13:23:56] but then the procedure in the checklist wouldn't work [13:24:01] with one in egress one in close [13:33:29] hmm right [13:35:25] while looking through those old chat logs I found something much more important [13:35:35] [17:24:38] man, I seriously owe Niklas a beer [13:36:58] haha [13:37:22] I think he said that more then once too [13:37:49] I won't forget it [13:39:42] but all the other behavior in the LM ECS is perfect when doing the Apollo 12 activation checklist, it agrees perfectly with the behavior [13:40:05] great [13:40:13] we put a bunch of work on it for that, haha [13:40:43] but we definitely had the behavior as on the AOH before [13:40:48] and then Ryan changed it [13:41:00] so I'm sure he had a good reason for it [13:42:59] oh [13:43:01] hmm [13:43:04] actually [13:43:27] I think that was just to make it cleaner code [13:43:31] not actual logic change [13:44:29] yeah [13:49:33] hmm [13:50:00] during that procedure press reg A is not in close [13:50:02] and it said [13:50:09] "or if one valve is set to EGRESS and then other valve is set to CLOSE." [13:50:13] the* [13:50:35] so that must explain it [13:53:56] in the regulator check, the press reg B is set to egress before the initial cabin dump to the master alarm, then after press reg A to close [13:54:05] yeah, after [13:54:19] first it does a auto repress [13:54:30] and switching press reg A to close immediately stops it [13:55:10] yes [13:55:39] but in our sim, it does not stop it it represses all the way even after press reg A to close [13:55:41] so the logic needs changing, both egress or one egress, one close inhibts auto repress [13:55:53] yep [13:56:07] yeah, we currently have it so that both regulators need to be in egress in order to inhibit auto repress [13:56:29] I'm not seeing anything in the Systems Handbook that would make the Close position special [13:56:36] but I guess that is how it should behave [13:57:09] I'll change that then [14:07:08] back in a bit [14:29:34] cya! [17:04:29] morning! [17:25:59] hey Mike [17:26:38] hey [17:26:39] what's up? [17:27:21] just fixing things here and there [17:27:23] and you? [17:27:38] getting ready for my lunchtime presentation on the AGC work [17:28:00] and looking forward to the weekend [17:28:21] counting the AGC stuff, tomorrow will be my first day off in four weeks, heh [17:28:54] ah, nice. And how much AGC stuff will the days off have?! [17:29:26] it remains to be seen how much of the time I will try to be productive, and how much I will spend laying around watching youtube or netflix [17:30:07] but my intention is to make the monitor able to inject channels into the AGC [17:30:14] and maaaaaybe get channels flowing from NASSP to it [17:30:55] I was thinking, the way we set inputs to the channels is a bit all over the place [17:31:09] some systems do it every timestep, others only when e.g. a switch is changed [17:31:27] would it be helpful to have all the inputs in one go? [17:31:42] hmmm [17:31:45] so putting it in one timestep function and they are all set/reset every timestep [17:32:06] I don't think the timing matters as much [17:32:21] how distributed is it? is there one function that handles all channel bits or is it spread all around? [17:34:11] all around [17:34:33] well, they all call agc.SetInputChannelBit or agc.SetInputChannel [17:34:39] but where that happens is all over the place [17:36:27] the only really central place is where yaAGC stores it [17:42:15] oh that's fine then [17:42:21] I'll just stick the code in those two functions :D [18:18:35] sure [18:20:51] I'm trying to be more sneaky about my channel injection [18:21:13] rather than inserting memory cycles, I'm now wondering if I can corrupt the instruction as it's loaded, so that it tries to access the wrong channels [18:21:46] that does sound sneaky [18:21:48] and then I can just have the monitor respond to those channels without any worry of real channel data being overlayed on top of it [18:23:42] but it's surprisingly difficult to figure out when an I/O instruction is being loaded... largely thanks to how much of a hack the EXTEND instruction is [18:26:14] it's difficult to hack a hack [18:28:47] indeed [18:28:58] you'd think it would be easy to tell what instruction is going on at any given time [18:29:05] but things like that make it quite difficult [18:30:40] oh, and I watched the latest video from Marc [18:30:49] two broken diodes, oh no, what will happen [18:31:14] if I only I knew [18:33:39] hahaha [18:35:28] guess we just won't be able to get it working. [18:41:17] yeah, too bad [18:41:22] at least you have your FPGA [20:07:09] night! [12:13:51] Indy91, u here? [12:13:57] hey [12:13:59] yes [12:14:11] how r u [12:14:45] oh fine, and you? [12:15:16] Did you see that last Orbter post of mine? [12:15:22] im ok [12:15:53] oh, now I have [12:16:11] "Apollo 15 trajectory parameters booklet" which one is that again? [12:16:38] operatal trajectory [12:16:47] ah [12:17:02] one of those that we got scanned I guess [12:17:07] from the Virtual AGC website? [12:17:09] hang on. let me find titile.... [12:17:46] Spacecraft Operational Trajectory for Apollo 15 [12:17:49] 71-FM-130? [12:18:21] hang on [12:18:37] yes [12:19:10] on which page does that have verb 71 data? [12:19:48] in your post you are mentioning both Apollo 14 and 15 [12:19:54] I guess you meant 15? [12:21:06] yes. that document has Apollo 14 V71 written down near the end of it [12:21:31] trying to find page now...... [12:22:15] I'm not seeing it in 71-FM-130 [12:23:08] Spacecraft Operational Trajectory for Apollo 15 (Mission J-1) Launched July 26, 1971 - Volume I - Mission Profile? [12:25:35] ithink i quoted the wrong document, but one of the Apollo 15 ones has those V71 [12:25:49] its not there [12:26:03] sorry [12:26:06] the Apollo 15 G&C Checklist has numbers like that [12:26:20] maybe thats it [12:26:30] https://history.nasa.gov/afj/ap15fj/csmgc/9-04.gif [12:27:19] Yes! [12:27:36] those. have you tried those? [12:27:39] that is not a state vector, that is a backup erasable load, also called padload [12:27:52] the numbers loaded in the AGC on the launch pad [12:28:03] basically configures the AGC for a specific mission and launch day [12:28:25] the AGC software is not mission specific, so it needs these numbers loaded in the erasable memory to work right [12:28:40] so all those V71s are for launch only? [12:28:56] well, this is actually for the cases where there is a computer failure during a flight [12:29:15] where all the numbers in the ersable memory get lost [12:29:34] so you would enter these numbers into the computer to get those mission specific numbers back into the computer [12:29:45] most of them are quite vital for the AGC to do useful things [12:30:05] and yes, those numbers were a good resource to figure out the padload for us [12:30:19] before we found the proper document that lists all the prelaunch erasable loa dnumbers [12:30:23] load* [12:30:35] if someone loaded a state vector into the AGC of Orbiter NASSP, would it change the spacecraft vector in the orbiter config? [12:31:11] in our T-4h launch scenario most of those numbers are already loaded, so doing it by hand isn't really necessary [12:31:17] ah yeah, part 2 of your question [12:31:22] no, it doesn't [12:31:44] plans to? [12:32:08] usually it's the other way around, you take the state vector from Orbiter, convert it to the right coordinate system and uplink that to the AGC [12:32:16] so then AGC and Orbiter are in perfect agreement [12:32:24] no immediate plans, but it could be set up [12:32:42] as you know we have some documents that list state vectors [12:32:56] the one that is available for Apollo 10, but not for 15 [12:33:02] or 8 or so [12:33:33] i was thinking of a situation were if we ever found those uplinked state vectors, historical, to accurately recreate an actual flight. [12:33:40] if we want to set up these kind of training scenarios then we would need to change the state vector of a vessel in Orbiter to those listed in the document/uplinked to the AGC [12:33:46] yeah [12:34:14] as I said, there is a coordinate system conversion necessary to get from Orbiter SV to AGC SV. But that would easily work backwards [12:34:26] so it would be quite possible to do that [12:34:37] you know that better than i do [12:35:27] where do you think these historical SVs are hiding? on paper even? [12:35:47] I think some are available for the J-type missions [12:36:15] where they had to know exactly where the CSM is to correlate photos and other science data to that [12:36:17] in what format, tape or paper? [12:37:10] yeah, theres a photo document out there for missions but its all lunar orbit [12:38:12] LOI DOI LANDING, not there [12:38:47] http://apollo.sese.asu.edu/SUPPORT_DATA/Apollo15_APE_Data_Book.pdf [12:38:56] yeah, all for lunar orbit indeed [12:39:07] yep, thats it [12:39:33] I'm not sure that the data that was uplinked and downlinked has survived [12:39:44] would you be able to get me some screenshots [12:40:00] from what? [12:40:30] view through the AOT at rest at landing [12:40:45] yes, sure [12:41:29] i have some LM moon star maps that they used and am trying to match up the stars [12:41:51] there also were pre-mission documents for this that would be really close to what actually happened [12:41:57] don't think we have that for Apollo 15 though [12:42:00] Im a star guy. Celestial navigation. sextant [12:42:30] all working in NASSP [12:42:51] although we haven't reliable been able to do sextant navigation with star/horizon [12:43:08] the split line-of-sight of the sextant is implemented in a quite annoying way [12:43:12] more of a Orbiter limitation [12:43:48] not sure i have that Lunar star chart. have to to bank and check which ones i got. i know i do have a POLLO 13 SLUNAR STAR MAP plus 2 hrs [12:44:25] http://www.ibiblio.org/apollo/Documents/19740073250.pdf [12:44:28] go to bank, safe deposit box [12:44:32] here is the document I was talking about from Apollo 11 [12:44:45] sure, I'll make your screenshots very soon [12:46:12] it's an old scenario, but very close to the actual landing site. Doesn't make such a big difference for the stars anyway [12:46:29] please wait till i get the exact Apollo Lunar Star Charts out. its been a big goal of mine to do that [12:47:05] but my Orbiter skills are so lacking. took time off [12:47:32] in a very old scenario I accidentally landed on the wrong side of Hadley Rille, oops :D [12:47:51] AGC clock was off, so that gave a large downrange error [12:48:13] makes the dune buggy ride that much more exciting [12:48:35] haha, yeah [12:48:58] the Lunar charts are actually planisperes [12:50:01] they rotate 360 degrees with six open loops for each AOT detent [12:50:24] yeah, took a while to figure that out for our AOT in NASSP [12:50:31] made our brains hurt a bit, haha [12:50:51] need to know the landing direction bearing of the LM to use them properly [12:51:46] im impressed greatly you implemented it into NASSP [12:53:04] yeah, it was challenging. We first had the spirale wrong, so that P57 alignments were off [12:53:10] but now they are quite good [12:53:15] not as good as the sextant in the CSM [12:53:22] but that wasn't the case in real life either [12:53:24] An Orbiter presentation should be at every Apollo 50th regalia [12:54:58] you should do one for your planetarium. ithink they would like it. Abbreviated of course [12:56:11] i can do pretty good with a sextant here in Utah. use homemade arficial level [12:59:47] when i get those Lunar star charts out next week ill connect with you, on German time haha. its 7 am here [13:00:23] take care. nice to chat with you. [13:01:19] yeah [13:01:24] cya soon! [13:01:27] later [13:58:14] hey [14:27:30] hey Alex [14:30:40] with all the IU updates I am adding some common failures [14:30:51] just of the liftoff/no-auto abort switch for now [14:39:01] good idea [14:39:33] can that be defined in the scenario? [14:40:25] hmm [14:40:36] with difficulty, but I can make that better [14:40:47] actually, I think we should make the failures mainly MFD based [14:41:13] in some cases we still want it defined in the scenario [14:41:18] like the Apollo 6 and 13 engine failures [14:41:35] but the PAMFD is a much better way to do it [14:41:45] for most failures [14:44:49] we can keep all current functionality [14:44:59] random failures, with failure multiplier [14:45:01] or scheduled [14:47:44] yep that makes sense [14:51:17] there is two cases where you would press that switch [14:51:22] in both cases auto abort is enabled [14:51:50] if the liftoff light isn't on then there is no power coming through the liftoff circuit from the IU [14:52:19] then you have no idea if auto abort is enabled, because that light can't be on either [14:52:45] if both lights go on at liftoff then only the auto abort relay hasn't been energized [14:52:55] pressing it will fix it and extinguish the light [14:53:57] in both cases auto abort gets enabled* [14:54:17] right [14:54:22] why you would trust the IU with auto aborts if that circuit already isn't working, I don't know :D [14:54:34] but the checklist says to press the button in those two cases [14:56:04] and those liftoff signals also start the mission and event timers [14:56:15] so they won't start if there is a failure [14:56:28] CMC gets a similar, but different signal [14:56:34] failure of that isn't implemented yet [14:56:37] but I can do that easily [14:57:27] one thing I think we should add maybe to the failure multiplier variable is an "off" value so that it will disable the random failure altogether. The reason being that sometimes you might want to have a scheduled failure and not have the random failures. This can already be accomplished with setting the failure multiplier very low, but I think an off value would be better [14:57:51] doesn't 0 work? [14:57:59] hmm maybe [14:58:02] nooo [14:58:09] divided by zero, haha [14:58:18] probably not healthy to try [14:58:22] but yeah, I agree [14:58:33] I had that when I tested the S-IC engine failure at T+5 seconds [14:58:38] got another failure, S-II engine [15:00:30] yeah [15:01:34] another reason to make it through the MFD, there you can easily prevent it from being set to 0 [15:01:41] instead of scenario editing [15:01:53] I should be able to add a page for that quite quickly [15:01:56] I guess in the PAMFD it could be like a random failures button which shows "off" or the desired ratio [15:02:02] yeah [15:03:15] I definitely like the idea of making it in the MFD [15:06:56] and I made the EDS to detailed now, I kind of want to implement this: [15:06:58] http://apollolaunchcontrol.com/Apollo_Launch_Control/Control_Panels/Pages/IU_Panels_files/Media/BB13%20EDS%20PREPARATION%20FR1/BB13%20EDS%20PREPARATION%20FR1.jpg [15:07:02] http://apollolaunchcontrol.com/Apollo_Launch_Control/Control_Panels/Pages/IU_Panels_files/Media/BB14%20EDS%20FLIGHT%20MONITOR%20FR1/BB14%20EDS%20FLIGHT%20MONITOR%20FR1.jpg [15:07:14] the EDS panels in the firing room :D [15:07:33] haha [15:08:03] setting the EDS to Launch on the prep panel is one of the last few manual steps in a countdown [15:08:04] I guess that could be an idea of an app that connects to NASSP [15:08:57] the very last manual step before auto sequence is setting the LVDA/ESE switch to LVDA [15:09:20] I think what that does is allow swich selector commands from the LVDC/LVDA to the stages [15:09:30] instead of from electrical support equipment [15:10:01] right [15:10:52] most of that is done automatically, but I found some procedure manually shutting down the S-IVB via the same commands as the LVDC would [15:11:05] in the case of a scrubbed launch [15:11:23] that can kind of be done through the PAMFD already [15:13:43] most of the commands there are still for ground equipment [15:15:45] I've been reading how SSU does the interactions between LCC, pad, ML and LV [15:16:02] definitely some improvements we can make, even without adding much new stuff [15:20:09] about the auto repress functionality in the LM did you have ideas about what could be added in the press reg a/b logic? [15:20:47] I guess all it needs is an extra check for the condition that one is closed and one is in egress [15:21:48] oh right, I forgot [15:21:53] I implemented and tested it [15:22:54] the only thing in the Apollo 12 procedure I am not getting is the "possble master alarm, cabin warning light (momentarily)" [15:23:05] but that is fine I guess [15:25:05] hmm, I think that is something I maybe should be getting [15:25:10] will test it again, then commit it [15:25:59] messed up the procedure a bit [15:26:47] and I have also a local change still for the LM RCS quad temps [15:27:14] changing the SCEA scaling, so the off scale low value won't have it show 20°F but -60°F instead [15:29:05] ok [15:29:08] I have conflicting sources what the SCEA should be scaling it to, but the scale on the right hand side of the meter definitely goes to -60°F, so that makes more sense to use [15:29:40] yeah [15:33:30] on a test yesturday I got a heater caution light because I think I left a quad to long pointed at the sun :D [15:35:24] hmm [15:35:27] good??? [15:35:30] or not :D [15:36:51] realistic I guess [15:37:20] in lunar orbit I doubt that would of happen as your only in the sun for an hour then in darkness for an hour [15:37:25] but this was in TLC [15:37:40] with a constant attitude [15:38:29] ah [15:38:33] yeah, I think that is ok [15:38:40] did the procedure again [15:38:50] cabin repress is in close [15:39:03] so not sure how there would be a master alarm/cabin warning light [15:42:05] probably just another weird thing with the physical implementation of this [15:42:18] and it said possible alarm, not certain, so I guess it's not so important [15:43:27] yeah I think that makes sense [15:43:49] the relay for auto cabin repress would have to get some spurious signal [15:45:36] updates pushed [16:06:17] works good [16:18:59] so in the Apollo 14 lunar surface checklist, post-EVA 1 repress procedure says CABIN REPRESS - AUTO then CABIN REPRESS CB - Close then (master alarm & cabin pressure increasing) and then only after that PRESS REG A & B from EGRESS to CABIN [16:20:02] but the cabin should only start re pressurizing after going from EGRESS to CABIN (as both were in EGRESS) [16:20:10] maybe thats a checklist error [16:28:45] so one thing we haven't implemented yet is that when the suit loop has low pressure auto repress is also on [16:30:41] but the suit loop should probably stay pressurized during an EVA, right? [16:31:28] 118:26:01 Mitchell: It's just a whine we're going to hear. Lighting: Annunciator/Numerics, Bright. (Pause) Cabin Repress, Auto. Circuit breaker. Cabin Repress, Close. (Pause) Okay, cabin (pressure)'s coming up. [16:31:32] 118:26:35 Shepard: Is the circuit breaker in? [16:31:36] 118:26:37 Mitchell: Say again. (Long Pause) (Press Regs) A and B to Cabin. (Pause) [16:32:55] pretty sure the suit loop stays pressurized [16:42:07] Cabin repress valve - auto [16:42:07] Press Reg A - cabin [16:42:08] Verify Master Alarm - on [16:42:08] Cabin warn lt - on [16:42:09] Verify cabin repress vlv opens [16:42:09] Master Alarm PB/LT - reset [16:42:10] Press Reg B - cabin [16:42:16] that's Apollo 11 [16:45:15] hmm interesting [16:51:19] but yeah, it's a bit of a mystery [16:51:48] and I don't think there was a relevant ECS change [16:51:59] AOH in all versions is quite clear [16:52:41] Apollo 12 procedure agrees with Apollo 11 (so our implementation) [16:54:42] morning! [16:57:58] hey [16:59:10] what's up? [16:59:54] hey Mike [17:00:14] ah, the usual [17:00:20] Alex finds issues, we try to solve them [17:00:57] same old same old :p [17:01:19] hehehe [17:03:37] im trying a fun test right now, in code the IMU case temp limits are 126-134 F. Im pointing the IMU case at the sun and I guess after some time I should get the TEMP light on the DSKY [17:03:57] depends on the isolation on that [17:04:02] which should be quite high [17:04:19] well [17:04:23] really small value [17:04:24] right [17:05:02] https://www.hq.nasa.gov/office/pao/History/alsj/a11/ap11-S69-36319.jpg [17:05:11] Apollo 11 CM closeout picture [17:05:28] I think those stickers on DSKY and CWS are not so up-to-date :D [17:06:06] especially those DSKY lights, but then of course the PRO key [17:08:14] oh thats weird [17:08:25] no idea from when that picture is, I've been trying to find out [17:09:15] but it was labelled as CM cabin closeout [17:09:33] whatever that means for the CM [17:11:16] huh [17:11:22] that seems...wrong [17:11:39] yeah [17:11:44] it's a nice collection of photos [17:11:45] https://www.hq.nasa.gov/office/pao/History/alsj/a11/ap11-S69-36314.jpg [17:11:50] READ THIS [17:12:25] https://www.hq.nasa.gov/office/pao/History/alsj/a11/ap11-S69-36315.jpg [17:12:27] Food Holder [17:12:40] is that just a piece of paper over the top half of the DSKY? I don't think any real DSKYs looked quite like that [17:12:52] haha [17:13:17] no idea [17:13:24] there certainly is no real program running [17:13:45] hmm [17:13:55] wait yeah [17:14:04] all of the recesses for screws aren't there [17:14:39] oh [17:16:43] I thought closeout was the final pre-flight preparation [17:16:48] for the LM [17:16:52] but this must be earlier I guess [17:16:53] well right [17:17:29] hmm [17:17:57] photo ID S69-36319 [17:18:06] so that probably means it was at least 1969 :D [17:20:11] yeah [17:20:20] very strange [17:23:00] 36319 [17:23:19] if the numbering system is closely related to date, S69-38860 is from July 1st [17:23:41] S69-35306 is from May 20 [17:24:44] I think it's just consecutive numbers for each picture as it was taken chronologically [17:25:02] so it'd probably be early-mid June-ish? [17:25:13] roughly [17:26:58] yeah [17:27:05] June 6 had the flight readiness test [17:27:25] and surely by the time the CDDT came around (July 2 and 3) it had to be in a more complete state [17:28:35] S69-35507, June 3 [17:29:17] S69-37994, June 23 [17:29:25] somewhere in the middle of that :D [17:29:32] hahaha nice [17:38:15] I'm not entirely sure how it worked, but maybe after the CSM flight readiness review responsibility was given from NAA to the KSC crews [17:38:29] so that takeover could be this "CSM closeout" [17:46:04] so the suit temps are actually pretty stable and correct already, I think enabling the suit temperature monitoring of CrewState should be ok now. Not cabin though [17:46:54] the instant you put a crew in the cabin the cabin temp skyrockets [17:49:09] right [17:51:35] /double heat = 138.72 * number * dt; //heat 1420 btu/hr (416.16092 W) total from CSM data book (Watts * number of crew * seconds = J/crew member/s) [17:53:20] so we use 30 there [17:53:26] up from 10, which we had used before [17:53:45] right [17:54:21] I guess 30 is closer to reality? [17:55:39] maybe [17:55:54] commit is called "Increase astronaut generated heat" [17:56:11] I think that maybe without it the suit temps would be too low [17:56:18] but Ill test with 10 [17:56:26] [22:06:34] .tell indy91, I think that number is really low (10 J/s) [17:56:29] haha [17:57:25] the number not used there, 138.72, seems to be correct according to the CSM Data Book [17:57:34] weird that even 30 seems too high [17:57:54] maybe the problem is rather that the heat is not going into the glycol loop [17:58:40] although [17:58:53] the number for lunar orbit is much lower [17:59:36] and maybe it is simply different in the CSM [17:59:42] because these numbers are for CSM [18:00:05] yeah [18:00:41] whats the number for lunar orbit? [18:03:16] 39 [18:03:23] so still higher than what we use [18:03:45] yeah [18:05:49] with 10 the suit temps get pretty low [18:12:34] well in maintains in the mid 50s F [18:12:56] found a number in one of the LM Data Book amendments [18:13:01] if I go suit temp to hot that helps bring them up a bit [18:13:09] 520 BUT/HR/MAN is a design number [18:13:16] average is quite close [18:13:23] but putting the crew in cabin definetly does not go too high now [18:14:46] I really don't think the heat from the crew is the real issue [18:16:00] it's that that heat isn't removed from the cabin [18:16:15] right [18:23:17] but putting them in the suits is ok, right? [18:23:24] suit loop can deal with the heat [18:25:50] yeah [18:26:10] its even on the cold side but still ok [18:42:00] cya! [18:42:36] indy91: I'm starting to poke around in NASSP [18:42:46] what's the difference beteween ICHAN and VICHAN in the scenario files? [18:44:20] ah [18:44:23] legacy code [18:45:02] when I was completely removing the old AGC++ I had some difficulties with removing the non-Virtual AGC input channel stuff [18:45:06] never went back to it [18:45:12] Not sure what was the problem [18:45:23] let's see... [18:46:40] VINCHAN saves vagc.InputChannel [18:46:49] so that is probably the right one to use [18:47:21] VICHAN* [18:47:31] looks like ICHAN is the same, but with channels 30 to 33 inverted [18:47:36] 34* [18:48:21] ah, gotcha [18:48:52] looks like ICHAN isn't even loaded in any way [18:49:00] so I should be able to just remove that [18:49:11] no idea what the issue with that [18:49:15] was [18:49:47] I have to keep loading VICHAN though, even though OCHAN has no "V" anymore [18:49:58] haha [18:49:59] or else those inverted channels are all loaded exactly wrong [18:50:06] hm, speaking of those [18:50:32] oh nevermind [18:50:46] channel numbers are stored in decimal, not octal? [19:01:33] yeah, looks like it [19:01:44] I wouldn't set it up that way, but it's too late :D [19:02:06] hehehe [19:23:46] by the way, have you ever seen any weirdness in the N64 LPD angle display? [19:24:07] for Luminary 99? [19:24:49] hmm [19:25:00] when we were messing around with the PDI scenario on the real AGC, if we managed to get it to automatically switch to the N64 display, the LPD angle would frequently have corrupted digits [19:25:17] oh [19:25:21] non-numeric displays [19:25:29] no, never seen that [19:25:32] but only in those two positions [19:25:57] seems unlikely to have been a hardware problem given how solid it was with the DSKY everywhere else [19:26:08] so I'm not really sure what was going on there [19:26:28] wasn't it a bit of an issue to get the middle digit to blank? [19:26:34] could it have to do with that? [19:26:42] and it was definitely real, because the problem showed up both on Carl's DSKY and on my monitor DSKY [19:26:58] how did you get it to switch to P64? [19:27:06] his going through the actual DSKY pins, mine going through watching channels [19:27:21] hmm, maybe it could have to do with that [19:27:45] we got it to switch to P64 by feeding in PIPA readings [19:28:03] Marc built a PIPA simulator and hooked up each axis to a potentiometer, so we could push the LM around [19:28:28] I wonder if that made it off by so far from the normal trajectory that weird things happened [19:28:35] could be, yeah [19:28:40] but still seems strange [19:28:45] there's no way we were following anything even close to a realistic trajectory [19:28:46] how would that even work [19:29:23] not sure [19:30:01] I don't know enough about how PINBALL makes the relay codes [19:30:57] maybe some weird overflow [19:31:19] what does the NASSP DSKY do if it's given an invalid relay word? [19:32:02] hmm [19:32:04] ah, good question [19:32:07] looks like it just returns a blank digit [19:32:33] yeah [19:32:48] so we wouldn't ever get that [19:33:06] I'd bet it has to do with the middle digit being blank and/or the trajectory being off [19:33:10] right [19:34:55] once I get this going I might put a debug print in ValueChar() to see if it ever picks up anything weird [19:35:41] any idea what the approximate PIPA inputs were when you got it to P64? [19:35:53] it switches when it is decently close to the P63 target conditions [19:36:11] so that is already not so easy [19:36:52] hahaha absolutely no idea [19:36:58] we were entirely doing it by feel [19:37:05] ok [19:37:32] our very last attempt we hit the surface at 20fps [19:37:38] which is not too bad, I think, haha [19:37:50] yeah [19:39:26] what code is for a blank digit? [19:39:36] to the DSKY [19:39:55] 00000 [19:40:00] ah, makes sense [19:40:05] so in ValueChar case 0 I guess [19:40:12] yep [19:48:51] uhh [19:49:07] already got one [19:49:18] code 16 [19:49:35] decimal [19:49:39] 10000 [19:51:25] in P63 [19:52:51] hmmmmm [19:54:04] https://virtualagc.github.io/virtualagc/traceDSKY.png [19:54:45] so it'd be 20 in that picture [19:55:16] well, good to know that the emulator does it too. but why... [20:04:25] yeah, weird [20:08:20] it's not so easy to rwach P64, but in a bad way [20:08:24] reach* [20:13:32] hahaha [20:13:36] I think we only got it once or twice [20:24:31] speaking of that, I'm sure there are some fairly reliable ways of supplying the right PIPA data [20:24:36] even without NASSP [20:27:58] I'll watch the PIPA data during a landing, just to get a feeling for it [20:34:11] :D [20:37:40] at ignition mainly -Z [20:39:43] it's simply a function of IMU pitch and roll [20:40:33] right [20:43:13] it's basically a spherical to cartesian coordinate transformation [20:44:41] but then comes the gravity [20:45:13] thrust and gravity together keep the PIPAX value close to 0 [20:46:08] until late P63 at least [20:48:12] sounds about right [20:48:41] when we were flying all we had was the PIPAs, and all the way down we were using X for vertical and Z for horizontal [20:50:07] sounds right [20:50:12] roughly [20:50:41] until late P63 [20:50:53] then it transitions into more +X [20:51:48] it starts with a bit -X [20:52:00] it's 15° travel away from the landing site [20:52:11] so the pitch is about 105° [20:53:44] well a few degrees more usually [20:54:01] you are pointing the DPS up a bit at ignition, just how the guidance equations work out [20:58:35] gotcha [21:03:27] oh, how did the presentation about the AGC work go? [21:04:54] good! [21:05:08] it went on a bit long but everybody was super into it [21:05:59] I bet [21:11:21] ah, some background to how the scanning of Don's listings started! [21:11:59] and my cameo [21:12:20] haha [21:12:37] yeah, I told the whole story from the beginning [21:12:53] at sort of a high level [21:14:35] I did find our conversation there when I was looking for some old comments from Ryan about the LM ECS [21:14:45] in the chat log [21:17:21] lots of funny coincidences along the way here, haha [21:19:09] oh yes [21:21:40] "Latitude of Manned Spaceflight Center programmed in for gyrocompassing" [21:22:07] it was funny when I wondered why it was 1° off, and then i went to google maps to check on the latitude of the MSC :D [21:22:14] hahaha yeah [21:22:38] that was an excellent find [21:22:58] well I was ready to determine which launchpad they were assuming for this [21:23:09] not thinking about where the AGC was located then [21:24:06] that didn't change much from the initial, wrong erasable file [21:24:11] hehehe [21:24:13] right [21:24:41] I can see where a 98 page presentation with mainly pictures on some pages might run long [21:25:24] I didn't know what to cut so I just went for it, haha [21:26:53] fun to see some of the "background material" which I hadn't seen yet [21:28:53] :D [21:35:49] yeah, funny coincidence, when you were first messaging Don I was working on figuring out what changes to Orbiter config files the AGC software needs to find anything on the lunar surface [21:37:07] haha wow [21:37:25] yeah our mutual timing was perfect [21:37:42] the end result basically was "Orbiter got it right", but I didn't know that immediately, haha [21:37:46] and you bumped that github issue exactly when I was trying to nail down emulator vs. simulator differences [21:37:49] for the Earth we needed modifications [21:37:55] hehe right [21:49:52] good night! [01:28:50] .tell indy91 I've fallen at the first hurdle [01:29:02] .tell indy91 I think the orbiter beta SVN is down [18:20:26] Hey [18:23:05] hey Alex [18:23:39] yeah, good timing to try install the Orbiter Beta for the first time when there is a rare server maintenance happening [18:25:20] hahaha [18:25:46] yeah [18:25:52] I got it now :D [18:25:59] Maybe a new beta revision? [18:26:01] waiting on other dependencies to download [18:26:15] no, the main SVN server is hosted on the Orbiter Forum servers [18:26:18] and those were down [18:26:33] yeah, they were doing a server resize [18:26:50] right [18:27:30] I was looking last night about how the heat can be taken out of the LM cabin better [18:27:50] I guess that would be through the cabin gas return? [18:29:43] not really sure [18:30:01] I was also looking at anything obvious controlling cabin temperature [18:30:10] but there doesn't seem to be anything [18:30:39] The suit temp rotary barely has any effect [18:30:57] And when it does sometimes the effect is opposite [18:31:04] right [18:31:11] for the suit loop [18:31:22] Yeah [18:35:57] oh, I found a very complex launch control system [18:36:04] will take you a while to figure out what is even going on [18:36:09] here it is [18:36:10] http://apollolaunchcontrol.com/Apollo_Launch_Control/Control_Panels/Pages/Spacecraft_panels_files/Media/CSM%20CONTROL%200054/CSM%20CONTROL%200054.jpg [18:37:15] Complicated indeed :D [18:37:42] hahaha [18:37:48] I believe this photo is from late 1966, so it might just be for https://en.wikipedia.org/wiki/SA-500F [18:38:26] would explain why there is not much to do for a CSM [18:40:17] Boilerplate csm? [18:41:17] good question [18:42:09] yeah, seems like it [18:44:45] Are you still thinking of making failures go through PAMFD? [18:45:03] yes [18:45:48] started with implementing to display which failure is enabled [18:45:57] Ah Nice [18:48:48] Anyways I’ll be back on tomorrow probably. Cya! [18:50:56] that CSM on top of SA-500F was M-11, the S/C Facilities Verification Vehicle boilerplate [18:51:06] which is now here: https://upload.wikimedia.org/wikipedia/commons/0/0a/KSC_Visitors_Center_rocket_garden_-_Saturn_IB_%26_F1.JPG [19:03:05] hmmm [19:03:13] why would a boilerplate have an on/off switch? haha [19:07:24] I'm imagining a single light bulb [19:09:09] hehehehe [19:41:17] thewonderidiot, a while back you were finding documents about Saturn ground computer stuff [19:41:31] among them a document called AS-503 Verification Test Programs, which is pretty great [19:41:39] ever found any automatic checkout sequences? [19:41:59] don't think so [19:42:33] I've scanned everything I got from that batch of ebay things [19:43:00] too bad that document has the EDS Preparation Test as "to be supplied at a later date" [19:45:30] and also too bad that the EDS test was done with the CDR on the pad comm loop, so all those Apollo 11 mission control loops that are available now don't have the audio for that test [19:45:46] not even BOOSTER [19:53:29] ahhh that's unfortunate [20:22:59] also everything needed for Orbiter setup has finished downloading :D [20:23:41] my goal for today is to get the NASSP DSKY wired up to my FPGA instead of the virtual AGC [20:24:07] that's a mighty goal [20:24:29] once I get NASSP building I think it should be fairly easy [20:24:59] among all the people who never properly tried NASSP, you are the most familiar with the NASSP code [20:25:18] hehehe [20:31:22] hmmm [20:31:29] it is mad about my D3D9 client [20:31:47] oh whoops [20:31:49] nevermind [20:36:53] okay [20:36:56] orbiter fully set up I think [20:36:58] now NASSP [20:37:33] nice [20:37:45] NASSP is small in comparison :D [20:38:22] so the post on the forum only talks about installing releases [20:39:05] so I just clone the NASSP repo right into the Orbiter folder? [20:39:28] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864.0 [20:39:45] ah, old forum [20:39:46] this is our guide for setting up git, if you want to do that [20:39:52] we should move that post to the new forum :) [20:40:01] https://github.com/dseagrav/NASSP/releases/tag/NASSP-V8.0-Alpha-Orbiter2016-1453 [20:40:10] you could also download the release here [20:40:36] if you don't want to commit and push anything then downloading that might be the easiest [20:41:09] nah, I'm going to be committing and pushing to a branch on my fork [20:41:16] ok [20:41:33] then mostly follow the guide on our old forum I guess [20:41:38] except with the Orbiter2016 brach [20:41:40] branch [20:41:41] not master [20:42:07] yep [20:42:22] a few posts further down I also wrote a guide how to set up NASSP by working with forks and pull requests [20:43:03] I doubt you will want to merge in any of the things I do to NASSP :D [20:44:11] probably not, yeah [20:47:20] I've been thinking about this though [20:47:29] having the monitor hooked up really makes a lot of this easier [20:47:57] because I can halt execution while Orbiter is paused, and load scenarios directly into the AGC [20:48:43] and now I'm thinking that I could even potentially do time accel by handing off to the virtual AGC during accel, and then jamming state back into the real AGC when you return to 1x [20:50:31] that would be quite awesome [20:53:23] okay, got my repository cloned [20:53:54] now, building [20:54:06] what Visual Studio do you use nowadays? [20:54:38] 2017 Community [20:55:36] so Orbitersdk\samples\ProjectApollo\ProjectApollo2017.sln [20:55:40] open that, build all? [20:55:44] anything after that? [20:56:09] I think that's it [20:56:17] if it builds without errors, haha [20:56:47] cool, it immediately failed :D [20:56:54] let's see here [20:56:54] Orbiter Sound? [20:57:18] "The Windows SDK version 10.0.17763.0 was not found." [20:57:38] oh [20:57:56] so maybe you need that then [20:58:20] the actually largest download of this process [20:58:34] haha uh oh [20:58:58] I remember that I had some problems figuring out the right version to download [20:59:10] but that was before Thymo updated everything to Windows 10 SDK [21:00:07] hmmmmmm [21:00:17] this is only listing older versions for me [21:00:23] guess I need to find something to update [21:01:05] in a recent update the vcxproj.user files have also caused problems for me [21:01:09] thanks Visual Studio [21:01:12] I had to delete them all [21:02:04] heh [21:02:12] okay, running updates, we'll see if that helps [21:02:35] https://stackoverflow.com/questions/50590700/how-do-i-install-windows-10-sdk-for-use-with-visual-studio-2017 [21:02:51] the Visual Studio installer had this version not in the list? [21:05:42] yeah [21:05:48] I think it's just because it's very old [21:05:59] I have at least 4GB of updates for it that are downloading right now [21:06:33] yeah, sounds familiar [21:06:51] a typical Visual Studio update, after which things don't work as they used to [21:07:04] hehehe [21:10:49] done downloading... [21:11:09] oh it's installing the right SDK version right now [21:11:10] perfect [21:17:57] okay, try 2 [21:18:08] now it's building :D [21:18:21] oh, I should be building Release, not Debug, right? [21:18:34] yes [21:18:53] debug is writing endless IMU and AGC channel data to files [21:18:56] I get like 5 fps [21:22:34] so far so good [21:22:57] we currently get two warnings [21:23:02] haven't fixed them yet [21:23:25] two warnings is not so bad :D [21:23:33] 33 succeeded, 0 failed! [21:23:37] yay [21:24:02] okay so now, I should be able to launch Orbiter_ng.exe and enable NASSP? [21:24:16] yeah [21:24:18] in the guide [21:24:19] Configure Project Apollo: [21:24:31] a few important steps in there [21:24:41] ah right, back on track with the guide [21:25:09] just a few small things [21:26:05] scenarios are under Project Apollo - NASSP [21:26:19] all the default ones are at T-4h, the usual prelaunch scenarios [21:26:44] there are also "Apollo - Mission Scenarios" [21:26:56] might be more interesting as a check [21:27:06] yeah, I'll probably be screwing around with the pre-PDI scenario [21:27:53] I think the scenario is outdated for the Checklist MFD, but you know which checklist to use [21:28:30] yeah, Checklist MFD is already at Lunar Surface Operations [21:28:36] hah [21:29:09] we added stuff to it, so scenario has saved the wrong spot in the checklist [21:29:35] speaking of mission scenarios, haven't tried Apollo 5 in ages [21:29:52] I wonder if that was broken by something [21:30:19] seems still good [21:33:44] hmmm [21:33:56] is there a way to make it jump to the correct checklist step? [21:34:07] I can navigate to the PDI checklist but it doesn't seem to want to highlight what I'm supposed to be doing [21:35:10] navigate to the PDI checklist and then press PRO until you are there [21:35:24] if you want it highlighted, enable the flashing borders [21:35:48] some button [21:35:53] ah, PRO, got it [21:35:55] FLSH [21:36:06] ah, that should be on [21:36:28] up and down and page up and down just scrolls [21:37:22] you can PRO to at least PDI-15 [21:37:29] scenario starts at PDI-12 [21:37:41] event timer is already set to count up to TIG [21:38:14] do you know how to navigate? [21:38:18] in the cockpit [21:38:27] you mean ctrl + arrow keys? [21:39:04] yep [21:39:17] and at some point you might want to yaw to heads up [21:39:25] how do I do that? [21:39:30] 1 and 3 on the numpad [21:39:37] 4 and 6 is roll, 2 and 8 is pitch [21:39:39] uh oh [21:39:43] what if I don't have a numpad, haha [21:39:54] try SCE to AUX [21:40:18] a joystick? [21:40:29] could try to get that set up [21:40:41] I mean, at some point the LGC forces you heads up [21:40:42] one problem at a time,t hough, I might have a keyboard with a numpad laying around somewhere [21:40:50] but that is later than you want [21:41:14] I think at 13k feet or so [21:41:28] then it will yaw you heads up automatically [21:41:36] well, I spent too long fiddling with checklists and missed PDI [21:41:47] let me see if I can find a different keyboard, haha [21:41:48] well PDI-2 it is [21:42:02] I think the MCC already supports PDI-2 [21:42:12] if you want to wait 2 hours :P [21:42:26] or just restart, haha [21:43:35] hehe yeah [21:43:42] well, I found a PS/2 keyboard with a numpad [21:43:50] now, does my computer have a PS/2 port [21:44:02] PDI-2 is actually not supported yet. [21:44:15] of course it has PS/2 [21:45:49] hmm [21:46:03] there is a single PS/2 port, that is half green and half purple [21:46:08] and when I plug in this keyboard nothing happens [21:47:52] you could also use the on-screen keyboard [21:48:08] I've used Orbiter with my netbook that way [21:48:14] not particularly fun, but it worked [21:48:30] I should get a standalone USB numpad [21:48:56] well I am glad you got it all set up. Have fun playing around. Good night! [12:09:47] hey [12:09:57] hey Niklas [12:10:30] I found the EDS Test in the Apollo 11 prelaunch audio [12:10:56] the checklist just says that the abort light will be on during that, but there is much more to it than that [12:11:03] a whole light show [12:13:11] with all the EDS updates I can easily implement a test sequence in that part of the prelaunch procedures [12:13:27] just some lights going on and off for now [12:13:29] oh nice [12:14:18] the real procedures involve the CDR pulling circuit breakers and testing all EDS related switches [12:15:10] sometimes there are multiple people talking at once in the channel, so it's not so easy to write down the actual order of all the tests [12:15:42] but I am getting the rough picture of what all is being tested [12:18:34] at T-1:38h right now, first they are setting one LV engine light to on at a time, now two at a time, lol [12:18:58] light show indeed [12:19:14] and Neil goes "1,2 on, 1,3 on, 1,4 on etc." [12:20:53] I was lucky to find this (BOOSTER loop, right channel), on every other mission control loop it is Mike Collins and the flight controllers talking about some slightly leaky fuel cell valve [12:21:15] the test is done with the CDR and LCC personell [12:21:22] so pad comm [12:24:12] interesting [12:31:32] oh, we had a checklist error that I fix [12:31:59] Apollo 9-11 had for some reason the SECS breakers and switches closed/on in the backup crew prelaunch checklist [12:32:27] there is a auto abort inhibit during the EDS test, or else, with the wrong switch settings, there might be a pad abort :D [12:33:01] the breakers are probably closed during parts of the test, but the switches, especially the pyro ones, would definitely not be up [12:34:17] one test was to have the THC in CCW for 3+ seconds, which would cause a CSM/LV separation. BOOSTER reported that he got an indication for that. So the SECS breakers are definitely in. [12:36:54] this EDS test went 30 minutes, definitely a lot going on [12:38:41] I bet [12:39:24] must of been nerve-racking to do the THC CCW even though the switches were off [12:40:42] yeah, Neil was hesitating for a moment :D [12:40:53] "1 second to CCW?" "No, 3 seconds minimum" [12:41:54] haha [13:45:32] of course the test of the liftoff circuit starts the event and mission timers [13:45:57] near the end of the test they are reset, but we don't have that in the checklist [13:46:59] and that concluded the test at T-1:32h [13:47:30] so maybe I'll not add any tests in there yet that require additional crew action [13:49:23] although, the timers should be reset and started at liftoff in any case [14:35:57] yeah makes sense [14:36:07] PR sent [14:37:12] and it's merged [14:37:52] thanks [14:38:33] trying to find the start of the EDS Test. Suddenly a reference to a Fred being able to egress now. I guess Fred Haise must have been in the cockpit at T-2:15h still. [14:38:44] and then a thick German accept, clearly Guenter Wendt :D [14:38:47] accent* [14:43:46] in the movie Apollo 11 you clearly hear his conversation with the crew and see him closing the CM hatch [14:50:03] ah, and I've finally been able to confirm what causes the LV lights to go on at T-4 minutes [14:50:35] it's not in the countdown documents, but it's two switches on the EDS panel in LCC [14:50:43] and I also know which relays they energize [14:50:52] sometimes it is really difficult to figure out the origin of a signal [14:51:15] for the liftoff discrete to the CMC I still only know that it is "some switch closure in the IU" [14:52:52] it's not in the Saturn Systems Handbook, pretty much every other signal between CSM and IU is in there [14:54:12] although in mainly covers the EDS in great detail. So maybe that signal does not originate in the EDS [16:08:57] posted the cabin temp issue: https://github.com/dseagrav/NASSP/issues/496 [16:15:31] good [16:15:38] oh, and BuildBot is working again [16:15:51] I wonder if that has to do with the Orbiter Forum maintenance/update [16:16:17] oh nice [16:45:17] I bet theres some people that think its the 1st release since March 15th :D [16:51:44] haha, yeah [16:52:54] morning! [16:56:00] hey [16:58:16] what's up? [16:58:47] managed to find the pad comm for the EDS test after all [16:59:13] on the BOOSTER flight controller channel, right channel only [16:59:16] because of course [16:59:49] seems to contain most of the launch control audio, although there is a lot of other channels talking over it [17:00:12] good morning [17:00:58] hey [17:01:30] oh nice! [17:01:34] that's cool [17:02:08] definitely heard Fred Haise (backup LMP) and Guenter Wendt [17:02:47] reentry is coming up on the 11 site [17:02:49] and the EDS test is a real light show, every EDS related light in the CM is tested in all possible combinations [17:03:05] astronauthen96__, with a good alignment I hope! [17:03:21] i hope so [17:03:37] if not, there always is the EMS :D [17:08:01] hahaha oh boy [17:08:34] I imagine it would be a bit nerve wracking to see all of those lights on [17:08:40] even though you know it's just a test [17:09:34] oh yeah, and they even test the abort circuits [17:09:46] THC to counter clockwise for 3+ seconds [17:10:07] that immediately would cause an abort, and at 3 seconds CSM/LV separation [17:10:53] the BOOSTER flight controller mentioned that he got the CSM/LV sep light on his console [17:11:26] throughout the test pyro and SECS logic bus switches are off though, so nothing can happen [17:11:28] still... [17:12:16] oh man [17:12:16] yeah [17:14:41] did you managed to get to your goal from yesterday evening? [17:14:44] manage* [17:28:31] no [17:28:42] because I forgot how ridiculously painful development on windows is, haha [17:28:52] and getting dependency libraries built and linked in [17:30:55] haha [17:31:15] you got NASSP to build and work, I'd consider that a great success [17:31:22] more than that even! [17:31:37] I have a build of NASSP that can connect to my monitor board over USB during AGC initialization [17:32:40] ah, nice [17:33:11] so I'm quite close, just need to write the class that does the monitor protocol and then add sending keys to the keypress functions, and change the display to get data from monitor channels [17:42:11] I also aaaaalmost did a landing [17:42:33] I got down to 100m up or so, and then it leveled out and eventually started to slowly go back up [17:42:46] I assume I was supposed to do something with the ROD but I didn't know how, haha [17:43:19] slowly back up is weird [17:43:21] I also had no idea where I was because my texture installation was screwed up at first so the moon was pitch black [17:43:52] if you do nothing it should do a nice auto landing [17:44:06] well, "nothing" [17:44:09] I was following the checklist [17:44:12] LR updates enabled etc. [17:44:35] which had me do PGNCS from auto to attitude hold (or something like that) pretty late [17:44:41] which I assumed was what had stopped the descent [17:44:48] ah [17:44:52] so you got to P66 [17:45:08] thewonderidiot, do you have a joystick slider? [17:45:29] I have joysticks but they are finicky and I was trying to limit myself to one problem at a time :P [17:45:53] ascending again in P64, P65 or P66? [17:45:58] um [17:46:15] I don't remember seeing P66 but I think it must have been that [17:46:28] anyway, https://www.orbiter-forum.com/showthread.php?t=40234 [17:46:34] Minus: Increase Descent Rate [17:46:34] Equals: Decrease Descent Rate [17:46:35] If you have a slider configured, make sure the slider stays at min, or else the thrust becomes the sum of the auto + slider setting [17:46:51] those are not numpad [17:46:57] I had the joysticks unplugged [17:47:01] right [17:47:11] pressing 0 on the numpad increases manual thrust [17:47:15] don't do that :D [17:47:20] yeah [17:47:26] haha [17:47:29] I don't think I did :P [17:47:43] before PDI I always press and hold numpad Del to be sure the manual thrust is at 0 [17:47:52] oh when I do the yaw to heads up [17:48:11] as I get about halfway there the LM nods off in another direction, and then seems to come back [17:48:18] I assume that's automatic gimbal lock avoidance? [17:53:17] did you do the manual yaw to heads up= [17:53:18] ? [17:53:40] yeah [17:54:00] pretty much right as the scenario starts, just hold numpad 1 or 3 for 180 degrees? [17:54:15] yeah [17:54:26] although that was rather done at PDI+4 minutes or so [17:55:14] as Alex said, there might have been some manual thrust commanded that screwed up the trajectory a bit [17:55:22] you would see on the engine thrust indicator [17:55:29] if the two needles agree or not [17:57:50] hmm [17:57:53] okay [17:59:51] I'll try again now that I can see the moon :D [18:11:45] yeah [18:12:24] maybe the LR dislikes a Moon without any installed/activated textures, pretty sure those data also contain the terrain [18:15:25] oh that could be haha [18:16:16] my N68 was hanging around 10000 (I forget if it was + or -) when the checklist was asking me to confirm that the readings were "close enough" [18:16:30] I didn't know what the acceptable range was but that seemed kind of high [18:16:57] haha [18:16:59] that's too high [18:17:14] in that Apollo 11 scenario it should start with about 3500 feet [18:17:18] and converge from there on [18:17:25] should be quickly below 1000 [18:17:29] hehehe [18:17:34] yeah that is probably part of it then [18:17:52] although, I did get a program alarm 511 at one point [18:18:00] the trajectory can get quite weird with these things [18:19:04] 511 is also strange [18:19:10] hopefully that goes away [18:19:51] haha hopefully [18:21:37] for a bit there was some fear that the landing site was too much uphill and that the LGC and LR would have major issues with that [18:21:41] it was in a Tindallgram [18:21:57] so weird terrain profiles could also make the LM ascend again [18:22:45] I think user error is vastly more likely [18:22:56] I think it's the LR [18:23:16] well, the black Moon rather [18:23:35] we'll see [18:24:11] I count having a black moon as user error :D [18:24:44] haha, true [18:49:29] AlexB_88, I separated from the S-IVB to do a Mode IV abort and somehow that broke the LVDC state vector [18:50:29] looking for the cause, maybe there is one timestep during the sep that has bad accelerometers readings [18:55:40] hmm weird [18:57:25] yeah, I think that is what happens [18:57:31] could also be related to a change I just did [19:13:04] interesting, it measures an acceleration [19:13:12] but when I undock the S-IVB from the LM then it doesn't [19:13:18] which is correct, it's in orbit [19:15:48] oh, hmm [19:15:56] S-IVB has a GetTotalMass function [19:16:06] which adds anything docked to it to the mass it gives to the LV IMU [19:17:47] I think that was used once upon a time for better attitude control of the old IU [19:18:10] right [19:18:38] probably not the cause of the one timestep where the LV IMU gave NaN accelerations [19:18:53] but definitely the cause of this 2 m/s² it measured wrongly [19:18:55] back in the throttle thruster days [19:19:14] yeah, which still worked with the Orbiter autopilots :D [19:19:26] throttleable* [19:19:37] yes [19:20:20] maybe the acceleration calculation simply breaks down when the IMU is suddenly in another vehicle, with different mass etc. [19:20:42] but still, I'd like to know why that becomes NaN [19:23:02] but this likely never worked [19:24:52] so this is LV state vector after CSM separation? [19:27:37] yeah [19:27:43] during powered navigation [19:27:53] for one timestep the LV IMU gives NaN as the acceleration [19:27:59] breaking the state vector in the process [19:29:32] I ran the S-IVB to depletion and then separated [19:29:43] I only wanted to look at the EDS in the scenario, but noticed the NaNs [19:47:56] AlexB_88, figured it out [19:48:28] the IU does its timestep in the Saturn class, and is then given to the S-IVB class [19:49:04] where it does its first timestep at the exact same time as the previous one in the Saturn class [19:49:27] so it calls the IU (including LV IMU) timestep twice during one timestep [19:50:09] and it uses the delta time in the LV IMU timestep [19:50:13] so it divided by zero [19:50:42] ah ok [19:51:44] thewonderidiot, cool stuff. Hopefully the landing will work out for you on the next try [19:53:40] the CSM/LV sep is in pre step [19:53:53] so it creates the S-IVB and does its pre step as well [19:54:04] so maybe all the stage separation stuff should be moved to post step [19:54:19] hopefully! I will get it to work once, and then break it terribly, and then maybe (if things go extremely well) in a few weeks get it to land again, haha [19:55:32] haha [20:03:13] indy91, hopefully that would fix it [20:03:30] yeah [20:03:41] there are lots of possible solutions, but that might be the best [20:04:25] well, it would have the same problem for post step again [20:04:37] does this mean all the TB8 stuff (impact burns, etc) have been inaccurate up until now? [20:04:39] S-IVB or IU aren't calling anything in post step, but still [20:05:23] I don't think it hurts in any other system to call a timestep function twice in the same timestep [20:05:45] so probably only LV IMU accelerometers readings are a problem [20:05:49] and only for one timestep [20:06:06] in TB8 it uses orbital navigation, so no accelerometers [20:06:54] ah ok [20:07:07] so its just after CSM separations from powered flight [20:08:04] yeah, so emergency CSM sep during TLI would also be a problem [20:08:29] which in reality would probably only be done because the SIVB was about to blow, so I guess an accurate IU SV was the last thing on their minds at that point :D [20:08:37] very true [20:09:02] and in a Mode IV abort the S-IVB just doesn't go correctly to LVLH right now [20:09:09] while it dives back into the atmosphere [20:10:25] I'll make the S-IVB skip its first timestep [20:10:38] easiest solution and also would work for post step [20:10:47] right [20:33:01] that seems to do it [20:33:12] Saturn and S-IVB class "clocks" are in sync [20:37:05] and of course no NaN [20:41:33] nice [20:49:34] a bit more testing tomorrow and I have yet another big IU update ready [20:49:37] good night! [21:37:41] Evening [21:39:46] hey [21:42:28] what's up, Thymo? [21:48:09] Nothing much. Just watching some DS9. Going to Thales tomorrow to talk about my internship in september. [21:48:16] nice! [16:43:44] morning! [16:44:47] hey Mike [16:45:16] what's up? [16:54:56] not much, just messing around with another Apollo sim: http://reentrygame.com/ [16:55:06] you? [17:01:14] I did a landing last night [17:01:30] well, first a spectacular crash that had me tumbling across the moon really far [17:01:44] and then I just gave up and let the AGC do it for me, and P65 set me down gently, haha [17:02:33] on the first landing, when I got into P66, I had forgotten what the ROD keys were and had to look it up in the chat logs from yesterday [17:02:48] and when I found them, the LM was going back up and had picked up a good deal of backwards speed [17:03:01] so I used the ROD keys to take it back down but it just kept going faster and faster backwards [17:03:14] and I didn't know how to null lateral speed so... [17:03:15] rough landing :D [17:03:29] haha [17:04:09] You probably got the crew dead klaxon on the 1st attempt, if the touchdown speed was higher then 50 fps [17:04:50] haha probably [17:05:05] I didn't have audio on but I wouldn't be surprised [17:05:29] you'd also see the crew dead message in the PAMFD ECS page [17:06:07] did you try with Apollo 11? [17:06:50] yeah, I was using the provided Apollo 11 pre-PDI scenario [17:11:35] btw how far did you get with P63 with the real AGC? I guess you were still missing a few inputs to get very far? [17:12:41] we made it into P64 a couple of times [17:12:57] we wired up all of the necessary switches and gave it a fake PIPA pulse stream [17:13:15] with potentiometers on the PIPA simulator so that we could tweak the sensed acceleration [17:14:17] on our last run we took it all the way down to the surface and I think touched the surface at about 20fps or so [17:14:21] oh interesting [17:14:44] but, like, super cheating, because we had no attitude control, and as much thrust as we wanted along all six axes [17:15:19] right [17:17:33] I guess you had some sort of physics simulation running to simulate the spacecraft/trajectory? Or maybe you just directly fed the acceleration data to the AGC [17:19:48] good evening [17:20:04] hey [17:21:03] I fixed the slight roll at S-IVB ignition [17:21:12] PMI? [17:21:18] ullage thrusters [17:21:34] ah [17:21:37] their direction was wrong [17:21:59] probably still is wrong, as is their position, but now they are pointed outwards from their position [17:22:34] hey indy91 [17:22:38] hey [17:23:05] I did one terrible P66 landing last night, that resulted in me tumbling very far across the lunar surface, and one perfect P65 landing [17:23:10] the AGC can clearly be trusted much more than me :D [17:23:44] haha, nice [17:23:58] the P66 failure was interesting, because after I switched to ATT HOLD the LM did start going slowly back up again... but also picked up a very good deal of backwards speed [17:24:16] well, you need to control the attitude right [17:24:19] yeah [17:24:29] look at tape meter for your descent speed [17:24:33] next time, haha [17:24:39] and do adjustments with the ROD switch there [17:24:45] and the cross pointer for you attitude [17:25:28] I need to get a joystick set up [17:25:29] you will definitely want to pitch down when you switch to P66 [17:25:41] works ok with the numpad as well [17:25:56] but, I'm pretty satisfied with the P65 landing [17:26:11] so I'm going to switch gears back to tying in the hardware AGC [17:26:19] I have a question for you there [17:26:44] due to USB latencies, there might be a one frame delay between when the AGC produces outputs and when I get those into NASSP [17:26:48] how much do you think that will matter? [17:27:52] not much for most outputs [17:28:29] most meaning that there are a few exceptions? :) [17:28:56] well, some need a fairly quick reaction time [17:29:04] but 1/60 seconds is nothing [17:29:24] I thiiiiink I should be able to hit that [17:29:25] even thrust and RCS commands not [17:29:44] RCS thrusters should have a delay anyway [17:29:51] if RCS gets to be a problem, I can integrate ontime in the FPGA and report that, instead of discrete states [17:29:55] you might make it more realistic if they are one frame late [17:30:01] hahaha [17:30:38] I'm trying to think of gotchas [17:30:42] I'd say 1/60 second is within the reaction time of any connected system [17:30:55] radars? [17:31:01] what if it's 2 frames? 1/30 second? that I know for sure I can hit [17:31:19] RADARUPTs are generated internally, so I just need to feed data in when the AGC asks for it [17:31:33] if I'm letting it do P65 I don't think I need to support HANDRUPTs right away [17:33:10] PGNS to AGS downlink :D [17:33:21] hmmmmm [17:33:33] with the queue thing you implemented I think that might not be bad either [17:33:53] which doesn't seem to work for RR data from PGNS to AGS, haha [17:33:56] I can capture what the AGC writes to the downlink channels and then just transform that into the right format [17:34:07] hmm [17:35:10] if a RCS on signal is delay then the RCS off signal will be delayed as well, right? [17:35:14] delayed* [17:35:42] if there were irrgularities there then the RCS might miss a on/off cycle completey [17:35:57] which is not entirely unrealistic though [17:36:00] that could happen [17:36:33] how do you deal with IMU data? [17:36:45] coarse alignments will probably not work with our IMU [17:37:36] hmmm [17:37:50] well, how would you like for me to deal with IMU data? :D [17:38:14] my naive plan was to just jam numbers into the counter registers [17:39:05] for sending things to the IMU... I can detect the difference between an instruction writing to a counter and a count cycle counting the number out [17:39:27] so I was thinking that perhaps I could latch the number as written by software, hand it off to NASSP, and.... magic happens and things work? [17:42:35] well we still use fictitious output channels from the Virtual AGC to handle coarse alignments and gyro torquing [17:42:54] ah [17:43:01] what's in those channels? [17:44:51] not entirely sure how it works [17:44:53] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_sys/yaAGC/agc_engine.c#L2371 [17:44:56] ah, so it just integrates pulses that have actually gone out, or something along those lines [17:45:01] I can handle that [17:45:30] channels 0174, 0175 and 0176 have coarse align stuff [17:45:52] 0177 gyro torquing [17:46:05] the rest is input and output bits, that should as usual [17:46:11] work [17:47:01] anything in real or fictional channels needs to call ApolloGuidance::SetOutputChannel [17:47:36] right [17:47:54] I imagine that all of that stuff can come later as well [17:48:08] if I want to start with a pre-PDI scenario and take it to a landing [17:48:29] yeah, no coarse alignment necessary during that :D [17:48:37] and because our IMU is perfect also no gyro torquing [17:49:00] hehehe [17:49:23] at first you need lots of input and output bits [17:49:29] and data from IMU to AGC [17:49:37] and THRUST [17:49:41] right [17:49:43] and I think all of those should be easy [17:50:05] just configure the monitor to latch the output channels and send them to NASSP once a frame [17:50:26] and send updated channels and counter register values over to the monitor every time NASSP updates them [17:50:42] quick question, what is the best document you can come up with that would information about the liftoff input bit for the CMC? [17:50:54] I guess a proper CDU simulation is what would eventually mot require any "fictitious channels" and stuff like that? [17:51:04] yeah [17:51:05] not* [17:51:09] for channel bit descriptions, my go-to is usually the Symbolic Listing Information [17:52:18] "Bit sensed as 0 if liftoff signal generated by S4B Instrumentation Unit, indicating that liftoff has taken place. Software uses this bit to halt pre-launch computations (with backup of a DSKY verb)." [17:52:23] what are you looking for? [17:52:24] I found a very unhelpful ICD, which didn't tell me much more then that indeed the signal comes from outside the AGC [17:52:55] well, all I have is "some switch closure in the IU" [17:53:08] I'd rather know where in the IU exactly and what relay is responsible [17:53:16] ahh [17:53:22] yeah no AGC document is going to tell you that one [17:53:31] and it's not in the Saturn V Systems Handbook? [17:53:36] that's the one thing the Saturn Systems Handbook did not have [17:53:40] damn [17:53:48] it has the other stuff from the IU [17:54:22] ullage thrust indication [17:54:25] is one [17:55:01] and of course there are two output bits to the LVDC [17:55:17] it has all the info about those [17:55:24] because it is very detailed about the EDS [17:55:35] so I think it's not in the EDS, haha [17:56:18] I'd really like to find some proper IU schematics [17:56:42] yeah that would be really great [17:56:46] it's too bad NARA doesn't have them :( [17:56:51] or at least [17:56:53] Fort Worth [17:56:57] maybe Atlanta does [17:57:03] yeah, possible [17:57:18] I have part numbers [17:57:20] or maybe the Grumman set of cards that is rumored to still exist [17:58:07] and I'm guessing the CSM systems handbooks just say "from the IU" [17:58:10] yep [17:58:18] it's very strange that it's not in the saturn systems handbook [17:58:54] hmm [17:59:08] it's quite specific in what it has [17:59:23] there are lots of signals going into and out of the EDS distributor [17:59:28] so it has details about that [17:59:39] each command from the LVDC flight sequence program [17:59:55] and it has a list of LVDC timebase starting logic [18:00:08] and that's the only place where it has the relay for the IU liftoff signal [18:02:48] is the discrete that goes into the CMC the same as the discrete that goes into the LVDC? [18:04:00] difficult to say [18:04:06] it will probably work ver ysimilar [18:04:32] dropout of a powered circuit through the umbilical [18:07:07] or maybe not [18:07:23] the LVDC would only start reading that discrete 1 second before liftoff [18:07:35] the CMC for ages before liftoff [18:07:43] so it might work differently [18:18:54] and I guess I also don't know the origin of the GRR signal [18:28:07] back later [18:46:01] hmm [18:54:22] GRR input for the CMC I meant, not LVDC [18:54:31] for the LVDC it is the ground computer in the ML [18:58:56] anyway, I doubt I will find out with the documentation that is currently available [18:59:12] so on to issues that I can actually fix or improve, haha [19:30:51] haha yeah [19:30:58] I'm struggling to come up with where that information would be [19:34:49] yeah [19:38:11] one hour left until the ASTP book auction [19:38:25] I ended up getting all of them except for apollo 11, 12, and 13 [19:38:35] all of the others went for reasonable prices [19:38:49] Apollo 11 went for $1225, and 12 and 13 both went for $900 [19:38:55] which I was not at all expecting, heh [19:39:21] wow [19:39:32] but nice that you got more [19:39:43] there is still a bit of an Apollo 14 terrain model mystery [19:40:02] you got the 14 one, right? It might help [19:44:19] If I had the originals of all scanned PDFs I have then I would be a rich man [19:49:06] yep, I got the 14 one [19:49:12] haha [19:49:32] assuming I win ASTP I'll have all except for 11, 12, and 13 [19:50:06] good collection [19:50:19] hopefully someday I will be able to complete it :D [19:55:15] man [19:55:27] I'm excited to start getting the FPGA tied into NASSP [19:55:54] yeah, that's a fun project [20:41:27] night! [12:33:41] morning [13:07:16] hey Alex [13:09:57] experimenting a bit with ML + Saturn interactions [13:10:11] when it comes to being memory safe a pad abort is really terrible right now [13:10:22] IU doesn't properly get deleted etc. [13:11:53] let's see if I can push what I did in the last few days, before getting too far into this [13:12:19] I can [13:12:39] whole bunch of stuff [13:12:51] the change to Saturn V PMI and rotational drag [13:12:54] weird. I thought it would delete itself like the normal abort [13:12:57] oh cool [13:13:06] S-IVB ullage thruster direction fix [13:13:26] some EDS failures [13:14:02] some changes to how the LVDC gets created and deleted [13:14:08] made it much simpler there [13:14:24] a (so far) small EDS test starting at T-1:55 [13:15:09] that's part of the reason why I want to change ML/Saturn interaction [13:15:21] so far the EDS test is done in the IU timestep [13:15:31] and there are some fake GSE relays for the EDS [13:15:56] when there should be some electrical support equipment systems in the ML [13:16:09] which the EDS accesses through the umbilical [13:16:30] umbilical also doesn't get disconnected quite right during a pad abort right now [13:17:19] pad abort wouldn't exactly disconnected the umbilical, haha [13:17:41] but for us there should be no data going through there anymore of course [13:18:37] ah and I also pushed the delayed first S-IVB timestep [13:19:51] and the docked mass issue fix, so the S-IVB + docked LM could do a TLI burn now [13:21:07] and most importantly, I managed to fix the VS just-in-time debugger :D [13:21:29] previously I could only do that if I started it all in debug mode [13:21:40] and when a CTD happened it never gave me the option to debug [13:24:10] uh oh [13:24:21] can you quickly check if a CSM/LV sep cause a CTD? [13:26:00] with the updated build of course [13:28:21] will do [13:29:04] thanks [13:31:30] not on my end [13:31:32] ah, I think it is something in a local change [13:31:33] yeah [13:36:05] calling the timestep of a deleted IU doesn't seem to work so well [13:39:05] I thought I could make the transfer of the IU from the Saturn class to the S-IVB class better, but apparently I can't [13:39:56] S-IVB class has a CTD when the IU gets deleted, probably because that IU was created and still resides in the Saturn module [13:40:01] Saturn dll* [13:41:50] right [13:42:18] is there a specific way of programming the new failures? [13:44:28] ah, right. Only by adding the right LAUNCHFAIL code in the scenario [13:45:01] LAUNCHFAIL 17 [13:45:26] 17, 33, 65 [13:45:35] 17 for Liftoff Signal A failure [13:45:39] 33 for B [13:45:44] 65 for Auto Abort Enable Fail [13:45:58] LiftoffA starts main panel mission and event timer I think [13:46:05] and B the ones in the LEB [13:47:41] oh [13:47:49] doing that gives me a CTD [13:48:22] damn IU [13:48:42] haha [13:48:57] this one probably affects you as well [13:49:26] what action caused it? [13:49:54] adding LAUNCHFAIL 17 to the scenario [13:50:30] IU hasn't been created when that is loaded [13:50:39] workaround is to add that line just below IU_END [13:53:00] 17 gives me an auto abort enable failure, haha [13:56:11] clearly I know what I am doing [13:56:43] oops [13:58:03] I probably just don't understand the LAUNCHFAIL status word right [13:58:29] hmm, 17 was correct [13:59:28] 17 for the LEB timers not starting [14:00:14] probably another local change that currently causes the No Auto Abort light to be in that case [14:01:00] yep I get the CTD [14:02:02] just put the after IU loading [14:02:06] the line* [14:02:18] below IU_END [14:05:06] ok [14:12:28] btw, were the SII & SIVB PMI's already accurate? [14:16:38] haven't checked yet [14:16:55] ok, the temperature is too high here today, haha, my brain isn't working right [14:17:24] haha [14:17:32] its high here as well [14:17:42] I think the extra auto abort enable failure is rather redundant [14:17:49] here is how it should work [14:18:12] liftoff signal A failure: LEB timers don't start, MESC A auto abort relay isn't set on [14:18:23] so that means both liftoff light and no auto abort light will be on [14:18:38] liftoff light powered through circuit B, and no auto abort on because of A [14:18:48] signal B failure will be the MDC timers and the same lights [14:19:02] if both of those signals fail, then no light will be on [14:19:15] and you should press the button to enable auto abort in both MESC systems [14:20:33] so a failure in both already covers the case where the liftoff light won't be on [14:20:49] that's code 49 by the way [14:21:10] LAUNCHFAIL 49 makes both liftoff circuits fail [14:21:20] I'll have to go, back in a few hours [14:21:22] cya! [17:09:07] morning! [17:21:42] hey [17:24:48] hey [17:24:50] what's up? [17:25:13] just trying some manual TLI's [17:25:37] how about you? [17:25:42] hahaha, fun [17:25:50] next AGC restoration video is up :D [17:25:59] oh nice, ill check that asap [17:26:37] and I started my NASSP branch last night. there's a proper class instantiated by apolloguidance that connects to the monitor when it's instantiated and closes the connection when it's destroyed [17:27:02] so tonight I'm going to teach it the USB protocol and hopefully get NASSP and the monitor talking a bit [17:34:41] very cool [17:34:54] will this eventually result in the actual AGC controlling NASSP? [17:35:05] that's the goal [17:35:15] awesome [17:35:21] optimistically, I could have the FPGA controlling the landing this weekend [17:35:36] I don't foresee any big showstoppers at the moment [17:35:54] it'll be limited to P65, since getting hand controller inputs would be much more difficult [17:36:01] do you have a CDU simulation as the interface or is there a workaround for that like we have in NASSP? [17:36:16] workaround [17:36:29] ah ok [17:36:30] the monitor can write values directly into the AGC's CDU counter erasable locations [17:36:39] which I think is more or less how NASSP does it [17:36:43] yeah [17:36:57] so I'm doing it the cheaty way at first, just to get it working [17:37:04] right [17:37:08] and then we'll take one step back at a time to make the interface more realistic [17:37:17] nice [17:37:47] hopefully once thats working, we can integrate that in NASSP [17:51:45] good evening [17:56:11] hey [17:57:21] I though for a second that the SII & LV GUID lights were broken after reloading in earth orbit, but I see that they are rather unpowered with the EDS switch to off lol [17:57:46] I am doing some manual launches and TLI's today [17:58:06] yep, they are powered by ED Buses 1 and 3 [17:58:08] nice [17:58:11] EDS* [17:58:55] all the lights on that panel are [17:59:07] LV lights etc. [17:59:26] separate light bulbs even, for redundancy [17:59:38] which Neil mentioned during the Apollo 11 EDS Test [17:59:51] that he could see if 1 or 2 lights are on [18:00:01] I was waiting for TB6 to happen and I was like "uh oh" what did he break now? "Oh EDS switch? Yep thats it! not broken, just more realistic :D [18:00:18] ah, EDS power [18:01:42] unrelated to the EDS, I did the manual TLI with Apollo 11, using the new checklists [18:02:00] worked ok, but MCC-1 is over 600 fps [18:02:08] hmm [18:02:13] I am pretty sure Ive done better then that before [18:02:32] I am thinking I may not be doing something totally right in the checklist [18:04:31] constant 4.5° yaw [18:04:59] and a pitch profile [18:05:24] and when did you cut off? [18:05:29] yeah [18:05:34] pad VI [18:06:01] hey Niklas [18:06:09] I am never quite sure if that should be cutoff or total DV [18:06:10] hey [18:06:20] pretty sure it's calculated as total DV [18:07:55] thewonderidiot, nice 210 alarm you got there [18:08:02] probably a difficult thing to fix :P [18:08:18] hehehe [18:08:30] actually, it is late cutoff [18:09:27] I did a test with my scenario right after cut-off. I immediately separated and pitched the CSM 180 degrees then burned for 120 fps [18:09:36] that brought MCC-1 down to 90 fps [18:10:12] so its not a wrong pitch profile at least [18:10:28] yeah, sounds mostly like it overburned [18:11:31] strange [18:11:58] one minor additional change I did, the S-II/S-IVB staging switch could be used in the Saturn IB as well for cutoff [18:12:10] that no longer works, no Saturn IB CSM ever even had that switch [18:14:25] ok [18:15:06] it must of not had the xlunar inject switch either [18:15:13] yep [18:15:25] and most also not the S-IVB/LM sep switch [18:15:33] ASTP had one there for the docking module [18:15:41] right [18:24:48] did you test all the EDS failure cases and combinations? [18:27:42] not yet [18:28:02] Ive been keen on seeing if I could get a manual TLI today, but Ill try those next [18:28:11] ah, no problem [18:28:31] I'll get rid of the auto abort enable failure anyway I think [18:28:42] I just tried another TLI, I used the cut-off VI that is shown on the manual TLI charts [18:28:43] it would just start the timers, but not the auto abort [18:29:04] much better, 195 fps [18:29:18] sounds good [18:29:43] 35575 on the historical pad [18:29:50] what did the MCC come up with? [18:30:11] 35602 [18:30:18] but this was after a manual launch [18:30:40] I had an ok orbit, but not LVDC standard lol [18:30:49] 103x97 at cutoff [18:31:01] that's nearly perfect [18:31:22] that was after a few attempts [18:43:12] the evasive burn helps in this case [18:43:51] I think Ive asked you this before but it escapes me, is Apollo 11 MCC compatible with 2nd opportunity TLI's? [18:44:31] I think it is, although it's not tested very much [18:45:00] "MCC1 will have to be executed" haha 1st time Ive seen that [18:47:22] so I guess if I recycle to the next TLI, MCC should give me a new TLI pad at some point [18:59:20] let's see [18:59:59] a few seconds after the predicted TLI cutoff the MCC checks on the flag in the LVDC for the second opportunity [19:00:25] if that is the case it waits until 3h GET [19:00:32] and then starts giving new PADs [19:01:29] the LVDC will have copied over the new targeting parameters for the second opportunity [19:01:37] so all MCC calculations will be done with those [19:01:57] I think it should work [19:02:34] ok thanks [19:04:33] by not tested very much I mean that I did try it once, for Apollo 8 :D [19:05:05] the next few events in the MCC happen TLI relative [19:05:11] so those should be also right [19:05:28] yeah, all of it is [19:06:21] maybe the flyby PADs comes too late and it will then also calculate MCC-3 too late, which is the first event relative to LOI instead of TLI [19:06:25] PAD* [19:06:47] I just got a CTD at the MCC-1 thread, but I think its because I was still undocked [19:07:11] oh [19:07:16] I just wanted to test the MCC-1 calculation so I didnt see the need to dock [19:08:00] is that the MCC-1 evaluation, if it has to be done, or the Maneuver PAD [19:09:05] hmm it just said "thread started" and then the CTD [19:09:15] I dont know if it was the pad 1st or not [19:09:29] oh its the actual MCC-1 [19:09:36] not the evaluation, that worked [19:09:54] manopt.enginetype = SPSRCSDecision(SPS_THRUST / (calcParams.src->GetMass() + calcParams.tgt->GetMass()), DeltaV_LVLH); [19:09:57] this line [19:10:25] most functions will just return 0 as the mass, if nothing is docked [19:11:43] but calcParams.tgt is the LM [19:11:48] and doesn't exist yet I guess [19:11:55] or didn't exist early enough [19:12:34] hmm [19:13:00] as far as I can tell calcParams.tgt is only set to something upon scenario loading, if the LM exists [19:13:08] well the LM existed, I had already separated from the LV [19:13:20] but not docked with it [19:14:33] I wonder if this is a general, and older issue [19:14:42] that you have to reload for it to recognize the LM [19:16:05] Apollo 10 only takes the CSM mass into account for the SPS/RCS decision for a burn [19:16:14] which is worse in a way, but at least no CTD :D [19:16:33] yeah, I think I'll have to add a check at the beginning of the RTCC function [19:16:42] or rather in the MCC [19:16:51] if LM exists now, save its handle [19:18:51] worked with the LM docked [19:18:57] 172.5 fps [19:19:06] after reloading? [19:19:10] I think I can still land on the moon with that :) [19:19:13] yeah [19:19:22] right now it seems to only recognize the LM after reloading [19:19:24] well I docked to the LM [19:19:24] otherwise, CTD [19:19:34] but I guess all I needed was reloading [19:19:37] for Apollo 11 only [19:19:39] yeah [19:19:52] only for 11? [19:19:55] I'll make the MCC search for the LM when a calculation is done [19:20:00] manopt.enginetype = SPSRCSDecision(SPS_THRUST / (calcParams.src->GetMass() + calcParams.tgt->GetMass()), DeltaV_LVLH); [19:20:15] manopt.enginetype = SPSRCSDecision(SPS_THRUST / calcParams.src->GetMass(), dV_LVLH); [19:20:19] find the difference [19:20:30] the first one is from 11 [19:20:37] which is right, but causes the CTD right now [19:20:46] Apollo 10 and probably 8 do the second one [19:20:49] for MCC-1 [19:21:19] calcParams.tgt->GetMass() being the problem [19:21:23] calcParams.tgt is NULL [19:21:24] right [19:21:41] that's for the Maneuver PAD, so it didn't happen earlier [19:21:44] ah [19:21:45] haha [19:21:51] and of course MCC-1 is rarely necessary [19:22:10] and fewer people will have done LM ejection to MCC-2 all without reloading [19:22:24] so the bug wasn't so apparent until now [19:22:29] but should be a simple fix [19:22:58] yeah [19:23:34] the irony in my manual TLI is that it forces an MCC-1, which probably would mean that I would get to the moon closer to planned time then if I didnt fly a manual TLI [19:25:02] possible [19:28:13] RTCC MFD w/ planning table says 4 mins early [19:30:17] nice [19:32:04] oh, how did you end up fixing the VS debugger> [19:32:07] ?* [19:32:34] regedit [19:32:41] some weird procedure I found [19:33:08] that window to select which debugger I want to use now opens twice though, haha [19:33:13] I overshot the target [19:33:37] I never even got that window before [19:33:55] Only if I opened NASSP in debug mode directly in VS could I do any debugging [19:36:45] do you have a link to that procedure? [19:37:11] sure [19:39:00] https://developercommunity.visualstudio.com/content/problem/260193/just-in-time-debugger-does-not-appear-after-crash.html [19:39:04] look for the post with [19:39:15] "To work around the windows" [19:39:15] etc [19:39:24] that's what I did [19:39:38] maybe if I only did the first part of it, the window would only appear once :D [19:39:44] thanks [19:40:03] it doesn't ask you if you want to debug then [19:40:08] Ill try it later tonight, and the EDS stuff [19:40:16] Ill be back in a few [19:40:19] it directly gives you the window with the list of debugging options [19:40:21] later! [19:40:28] cya [20:29:26] night! [12:52:06] hey [12:53:52] hey Alex [12:55:54] really didn't like that the EDS test was in the IU code, so I moved it all to the ML [12:56:12] or rather a common IU ESE class, which the ML, LC-37 and LC-34 all have [12:58:09] now I also don't have to have lots of bools in the IU that are GSE signals [12:58:36] it just calls a GSE function in the IU and if the umbilical isn't connected then it just returns false [12:59:52] eventually parts of this will be moved to a LCC vessel, but I guess for now it can be in the launchpad code. [13:02:03] makes sense [13:03:10] at one point I will continue with Apollo 8, but for now I am having too much fun with this [13:03:19] as for the bugs, I'll have them fixed, just need to test it [13:03:20] did you manage you figure out how to handle the IU deletion issue after pad abort? [13:03:24] MCC not finding the LM [13:03:29] LAUNCHFAIL CTD [13:03:41] not quite yet [13:03:44] but I have some ideas [13:04:47] I tried a Check S-IVB Systems function, like we have for the SM [13:05:14] but that will need a bit of special code for not deleting the IU, if it was just given to the S-IVB vessel [13:05:33] because the S-IVB can't delete the IU, if it was created in the Saturn dll [13:05:43] but probably just needs a status flag [13:06:02] bool DontDeleteIU, only set true when the IU was just given to the S-IVB [13:06:22] I think that should work. Except for that special flag this is a fairly clean solution [13:06:32] right [13:07:04] and I moved IU creation from IU loading to the loading of the STAGE parameter [13:07:12] oh btw, last night I tried a very unlikely case [13:07:39] that will fix most of the LAUNCHFAIL scenario parameter CTD cases [13:07:48] manual launch + TLI after 3 hour launch delay + 2nd opportunity TLI [13:08:15] haha, wow [13:09:00] how did it go? [13:09:02] worked quite good, except I think MCC didnt like it too much :D [13:09:31] too bad :D [13:09:35] where had it problems? [13:10:02] It gave me a TLI pad and everything for the 2nd TLI, but at the end of the TLI burn itself, I saw a "start thread" "end thread" happen twice in succession [13:10:20] that's not necessarily bad [13:10:28] just means two separate calculations taking place [13:10:35] right at the time that it useually just says "TLI" or something like that but I didnt see that [13:10:50] ok, that is probably bad [13:10:54] ooh [13:10:57] haha [13:11:14] and then afterwards I did not get any other message from MCC until 11:15 MET which was just a "thread started" and nothing else [13:11:17] I think I might know an issue with the 2nd TLI opportunitiy support in the MCC [13:11:48] it might have recycled you to EPO logic again [13:11:58] because it saw the second opportunity TLI flag [13:12:06] it also needs to check the TLI permanently disabled flag [13:12:13] or whatever I implemented there in the LVDC [13:14:04] ah [13:14:04] bool INH3; // Permanently inhibit entry to restart preparation [13:14:06] this one [13:14:20] easy change I think [13:14:32] not sure what it did at 11:15 MET for you though [13:15:55] that would b the MCC-1 pad I guess [13:15:58] be* [13:17:12] well, I kind of doubt it even got there [13:17:22] the MCC logic might be stuck in Earth orbit forver [13:17:28] ah right [13:17:28] any idea what the MCC state was there? [13:17:36] ill check [13:18:40] mission state 12 substate 6 [13:18:52] thats just before the 11:15 thread [13:19:22] case MST_G_EPO2: //TLI+90 Maneuver PAD to TLI+5h P37 PAD [13:19:27] Mission phase 2 Earth Rev 2 [13:19:33] so it's a TLI+90 PAD calculation I think [13:19:38] Earth Rev 4* [13:19:41] right [13:20:36] I'll just check if it is in TB7 [13:21:13] or rather TB6 or higher [13:21:54] if TLI was late for some reasons [13:22:26] early TLI cutoffs aren't supported anyway [13:22:30] by the MCC [13:22:42] even a 1 second TLI burn will have it cycle to TB7 [13:30:35] most late TLI cutoffs will still have a normal lunar mission of course [13:34:34] fitting: https://twitter.com/NASAGroundSys/status/1144229255724900352 [13:34:42] SLS ML is on the way to LC-39 [13:36:10] nice [13:36:34] looks a lot like the saturn 5 LUT [13:37:33] Ill be down there for the 1st week of July, maybe they will still have it out [13:38:05] " The mobile launcher on it's way from the Vehicle Assembly Building to Launch Complex 39B, where it will undergo three months of testing in preparation for the launch of Artemis 1." [13:38:19] so sounds like it might be there, haha [13:38:24] nice [13:47:58] so a during a guidance reference failure, the LVDC can still do navigation I guess [13:48:19] because timebase 6 still starts automatically at the correct time [13:51:02] yes, although I am not quite sure how they would have handled in on Apollo 11 [13:51:10] probably a failure during launch [13:51:15] and then a IU state vector uplink [13:51:18] that should fix it [13:51:34] ah right [13:51:56] the way we do GRF might also not be super healthy for the SV [13:52:00] for one timestep [13:52:26] the SV accuracy is still pretty good in orbit [13:52:30] ah, ok [13:52:33] at insertion* [13:52:55] and I guess we still do the SV update anyway [13:53:02] ah, haha, the code that makes the LV IMU bad is disabled [13:53:07] so it simply has the status failed [13:53:13] { [13:53:13] double failang = 20.0*RAD*deltaTime; [13:53:14] Orbiter.AttitudeReference = mul(Orbiter.AttitudeReference, _M(1.0, 0.0, 0.0, 0.0, cos(failang), -sin(failang), 0.0, sin(failang), cos(failang))); [13:53:15] }*/ [13:53:22] this would have rotated the platform at 20°/s [13:53:27] and then the LVDC would detect that [13:53:33] and not use the IMU data anymore [13:53:42] probably didn't work perfectly yet, so it's commented [13:54:43] in LVDC code it does indeed not update the current attitude [13:55:01] but still uses accelerometer data [13:55:09] so powered navigation just works as normal [13:55:48] the LVDC would actually simulate some navigation for itself based on its own calculations of desired attitude and expected thrust [13:55:53] but that isn't implemented yet [13:56:12] then we can handle the GRF properly [13:56:34] ah I see [13:57:05] I guess right now if we throw the IMU at 20 degree/s the LVDC will never be recoverable [13:58:13] yeah, powered navigation gets broken [13:58:21] which isn't used, but still needed for the SV [13:58:30] isn't used for controlling the Saturn I mean [13:58:48] in tests it worked quite well iirc [13:59:02] you see that for one timestep the Saturn gets thrown off a bit [13:59:08] but then with the GRF it recovers [14:01:40] right [14:04:49] ok pad abort seems memory safe. But on my first attempt the main chute didn't open in time and I landed hard [14:05:28] I had random failures on, I wonder if that was a general bug with my changes right now, or a random ELS automation failure [14:05:40] should have tried to check :D [14:05:57] in mission control Im sure theyre saying "we killed the crew, but on the bright side, it was memory safe!" [14:06:37] haha [14:06:39] everything seemed late [14:06:48] but even with a hard landing the main chute should open [14:06:50] which it didn't [14:06:53] must have been a failure [14:07:49] 1 in 128 chance for that [14:09:08] I guess it really wanted to confuse me [14:09:13] haha [14:09:45] Im pretty sure Ive seen that it one of my tests [14:12:09] looks good all around [14:12:23] IU creation/deletion is much better now from a coding point of view [14:12:41] I just shouldn't do too many changes at once, haha [14:13:28] I'll just test what I have now [14:14:22] because I am going through the Systems Handbook for any ground commands to the IU I even added the beginning of the logic for switching the IU to internal/external power [14:15:49] neither IU batteries nor ground power is implemented yet of course :D [14:21:01] I guess one day those will be needed [14:21:44] indeed [14:35:04] one thing I had noticed in the past was when you scrub the launch with the EDS switch, the addforce stays active after the liftoff time has passed [14:37:07] the LVDC is stuck in Timebase 0 [14:37:17] and that's where the holddown force is [14:37:47] how do you notice that it stays active? [14:38:15] I guess the force should be moved to ML/LC-34/LC-37 [14:40:29] if you put the EDS switch back on after the scrubbed launch, all engines will start, but the stack stays in place because of the addforce [14:40:47] ah, right [14:40:56] and the engine will burn on the pad until fuel exhaustion [14:41:13] well done me, I implemented a static fire test [14:41:22] haha [14:41:48] but about moving the addforce to the ML, would that even work? [14:42:11] I thought you had to have it inside the vehicle that you want to hold back [14:42:33] I remember that there might be some issues with it, but right now I'd think yes [14:42:54] but the ML is a separate vehicle to the saturn 5 [14:43:10] can still call a function to add a force to it [14:43:21] ah I see [14:43:40] about the EDS switch [14:43:42] maybe that would also take care of the pad abort at ignition issue [14:43:48] yeah [14:43:59] you switch to off before the igntion sequence? [14:44:04] and then on again [14:44:30] after T-0 [14:44:51] yes [14:45:13] we have no countdown holds yet of course [14:45:29] but one thing that should prevent this is a cutoff signal that gets sent at T+6 seconds [14:45:42] according to a very old document [14:45:44] late 1966 [14:46:06] so I'll make it send that out [14:46:22] if you switch EDS power on between T+0 and 6 it might still start [14:46:39] but it would just get cut off before reaching full thrust [14:48:45] and then stay in cutoff forever [14:48:57] because no LCC to reset it [14:49:39] hmm [14:49:59] on my late launch scenario from yesterday I cannot replicate that issue [14:50:17] it's quite timing dependant I think [14:51:13] maybe only between -16.2 and -4.9 seconds [14:51:15] but I found something else, when I flipped off the EDS switch at around T-10s, the engines fired for about a second [14:51:18] switching EDS power to off [14:51:28] oh [14:51:34] like right when I flipped it off at -10s [14:51:35] probably does a normal shutdown sequence [14:51:42] starting at full thrust... [14:51:55] you are finding too many issues at once again... [14:52:02] haha [14:52:32] it didnt fire for a second at the tliftoff time, but rather when I flipped off the EDS switch, at -10s [14:53:47] yes [14:53:52] it sent a cutoff to the S-IC [14:53:56] right [14:54:09] and it does a normal cutoff sequence, which starts at full thrust [14:54:16] no check yet how high the thrust actually is [14:55:05] or was before cutoff was commanded [14:56:10] it's handled a bit better with the J-2 engines [14:56:31] if thrust is 0, then it won't suddenly start at thrust 1 when a cutoff is commanded [14:56:40] I'll probably do that for the F_1 engines as well [14:56:44] ok [14:59:06] even the H-1 engines already had that [14:59:08] just F-1 not [15:00:01] I checked what happened if you stay in Timebase 0 forever [15:00:09] at T+150 seconds TB1 is permanently disabled [15:00:30] at T+497 the LVDC starts operating one IU ECS water valve [15:00:51] such a capable computer, and then all it does is cycle a single valve every 5 minutes :D [15:01:26] nice [15:03:34] remember how you were confused yesterday why no EDS lights were on with the EDS power switch off? [15:03:45] I just did that to myself [15:04:24] back in a bit [15:22:12] haha [15:46:22] I'll test hold down force in the ML now [15:48:40] only applied if no cutoff [15:49:04] in what case did the force pull on the CM? [16:07:35] hmm pad aborts [16:07:56] while the addforce was active [16:08:21] ah, right [16:13:52] is the addforce still in saturn and being called by the ML? [16:14:38] AddForce is a VESSEL method [16:15:20] so ML just calls sat->AddForce [16:15:24] same function as before [16:15:26] on the first test the issue still happens [16:15:51] but, it might be an advantage that the ML timestep is done after the Saturn timestep [16:19:45] right now only the cutoff signal prevents the AddForce [16:19:51] but I'll put a stage check on it [16:19:58] that might fix it [16:20:30] ok [16:21:15] so I would think the order is: abort, stage CM_STAGE, ML checks stage, no add force [16:21:24] but the ML has to realize that in the same timestep [16:22:03] yes! [16:22:12] that does it [16:23:03] so I'll move the add force out of the LVDCs and put a stage check on it [16:25:12] nice :) [16:46:00] morning! [16:55:51] hey Mike [17:04:02] hey [17:04:14] I got most of the communications framework done last night [17:04:29] https://pastebin.com/KTxj43as [17:04:48] that's my NASSP monitor log [17:04:58] successfully reporting the value of the FPGA's Z register once a frame [17:05:11] so now I have access to everything the monitor knows in NASSP [17:05:18] in theory the rest should be relatively straightforward :D [17:05:55] awesome [17:06:42] so where in NASSP code are you accessing data? [17:06:56] SetInputChannel? [17:07:17] probably, I haven't added any hooks yet [17:07:44] https://github.com/thewonderidiot/NASSP/blob/agc_bridge/Orbitersdk/samples/ProjectApollo/src_sys/AGCBridge.cpp [17:08:24] https://github.com/thewonderidiot/NASSP/blob/agc_bridge/Orbitersdk/samples/ProjectApollo/src_lm/LEMcomputer.cpp#L133 [17:08:29] this is what produced that log [17:08:58] I've added an "AGC Bridge" class to apolloguidance, and am only instantiating it in LEMcomputer right now to keep things simple [17:09:57] ok [17:10:15] my thinking was that I could then just stick calls to it throughout apolloguidance [17:10:15] there is actually a bunch of cases where we directly manipulate AGC memory [17:10:28] yeah, I'm going to have to track those down [17:10:47] LR, RR, VHF Ranging, Uplink [17:10:53] CDU class, used for RR [17:11:02] CMC optics I/O [17:11:23] we also have a function called SetErasable [17:11:39] do you always go through SetErasable if you are modifying memory? [17:11:44] nope [17:11:47] haha [17:11:48] we should [17:11:49] okay [17:11:56] I can definitely change that [17:12:02] that would help a lot :D [17:12:07] no problem [17:12:26] although [17:12:28] bit of a problem [17:12:35] CMC optics for example [17:13:01] right now we modifying the read counter data directly, when the sextant is commanded to move [17:13:08] if (val12[EnableOpticsCDUErrorCounters]){ [17:13:08] sat->agc.vagc.Erasable[0][RegOPTY] += pulses; [17:13:09] sat->agc.vagc.Erasable[0][RegOPTY] &= 077777; [17:13:09] } [17:13:23] so that's not quite as trivial as calling SetErasable [17:13:55] but we could do GetErasable, do the operation, then SetErasable [17:15:00] hmmm [17:15:35] that wouldn't work interfacing with a real AGC [17:15:53] because the AGC is going to be screwing around with that number as well [17:16:45] well, not when if (val12[EnableOpticsCDUErrorCounters]) isn't true [17:17:13] it only zeroes that specific numbers I would think [17:17:22] but of course, how we do that is bad [17:18:16] that also doesn't matter as much for the first goal of going from pre-PDI to landing :D [17:18:41] yeah, fixing the LR case should be easy [17:19:01] lem->agc.vagc.Erasable[0][RegRNRAD] = (int16_t)(12288.0 - (rate[0] / 0.643966)); [17:19:25] and the other 3 instances of that in LR code [17:19:31] should be calling SetErasable [17:20:04] lem->agc.SetInputChannelBit(013, RadarActivity, 0); [17:20:04] lem->agc.GenerateRadarupt(); [17:20:07] are these a problem? [17:20:14] RADARUPT? [17:20:24] yeah, that's what I'm looking at right now [17:20:32] the AGC generates RADARUPT internally [17:20:36] yeah [17:20:54] so the tricky part is making sure that you set the RNRAD location on time [17:21:02] between when it asks for the data and when it generates the rupt [17:21:15] but I just realized that it might force shift counts internally as well [17:21:29] so it might corrupt anything you put in there unless you sneak it in after the last count [17:21:38] I'm sure we could find an intermediate solution for this, which doesn't require completely going to your pulses Virtual AGC change yet, but works better for the AGC [17:22:07] ....but I don't think that's the case, I think as long as the turnaround time is fast enough it should work [17:22:41] I actually used to think that giving the data too quickly to the LGC was the cause of our LR inaccuracies :D [17:23:17] it was of course something unrelated, but there is a bit of a delay there [17:23:34] yeah [17:23:39] it's 90ms? [17:23:45] something like that, yeah [17:24:07] so about 5 timesteps [17:26:17] yeah, we should be able to hit that [17:26:45] between detecting the channel bits are set and getting the data in [17:27:13] and thinking on it more I'm pretty sure the counts aren't forced [17:29:22] the data in the LR is there, just needs something from the LGC to get it the "right way! [17:29:23] " [17:29:29] counting it out to the LGC or whatever [17:29:32] yeah [17:29:44] the other alternative, if for some reason we can't make the cycle fast enough [17:30:06] would be to just calculate the results for each channel every frame [17:30:15] and send it to the monitor every frame [17:30:27] so that the monitor can just respond with its latest data upon request [17:32:08] yeah, possible [17:32:14] more work for your monitor :D [17:32:57] hehehe [17:33:01] yeah [17:33:29] automatic memory cycles would be interesting with the current architecture, and this would require those [17:33:43] I've successfully avoided needing to introduce them so far [17:34:00] so hopefully the radar doesn't end up needing them :D [17:35:15] as I said, if it is possible, then we make our LR "pulses ready", with some changes to our Virtual AGC version [17:35:47] back in a bit [17:37:00] kk [17:55:10] if we could do it subsystem by subsystem then it would be much less of a pain to eventually change to the updated yaAGC [17:55:57] yeah for sure [17:56:19] we can definitely make that work [18:07:39] that would be great. I'm definitely willing to do lots of changes to our systems to make it work better with a real AGC, but changing everything to pulses is a bit much in the next month [18:08:07] oh yeah, for sure [18:08:49] to be honest I'd prefer if NASSP didn't change at all in the next month, minus making interfaces more clean (e.g. funneling everything through SetErasable) [18:09:00] it'll be easier to get it to work without having a moving target :D [18:09:15] yeah, agreed [18:09:44] I'm just changing Instrument Unit and GSE stuff at the moment :D [18:09:52] er, that came out wrong, haha [18:10:02] I meant, let's not restructure AGC-related stuff in the next month [18:10:09] I'm totally happy for the rest of NASSP to continue changing :D [18:10:11] yes, that's what I mean :D [18:10:44] I agree that AGC related changes in the next time would be bad, luckily I am mostly working on IU and GSE anyway [18:12:12] making the IU even more ready for using real LVDC software, which of course will become freely available next month... [18:12:57] if only [18:14:12] I almost believed you for a second :D [18:15:04] I guess we would still need an LVDC emulator [18:15:16] true [18:15:24] I believe it works similar to the AEA though [18:15:41] so it would be difficult, but not impossible [18:16:14] gives Ron something to do that isn't schematics [18:16:51] Id also nbe equally happy to just find the remaining full presettings of each mission [18:16:55] be* [18:18:48] yeah [18:18:51] especially Apollo 10 [18:19:01] NTRS has it, but doesn't want us to have it [18:19:21] bummer [18:19:31] once we have LVDC code, you can be darn sure that there will be an emulator within a few days :D [18:20:04] haha I bet [18:20:37] and most of what I have to do is move the little bit of remaining non-LVDC code out of our LVDC [18:20:51] and start setting up external interrupts and discrete inputs [18:23:13] I guess the addforce was another one that didnt have its place in the LVDC [18:24:00] yep [18:24:06] and I also removed GetAltitude [18:24:14] and GetFirstStageThrust [18:24:22] that was used to determine the AddForce number [18:24:43] right [18:24:49] now there is not even that many GetMissionTime left [18:25:13] are the aborts still working well as your initial tests with the addforce change? [18:25:42] working fine [18:25:47] even the main chutes open [18:26:18] thewonderidiot, on the very first test of this hold down force change I accidentally had failures enable and the main chutes didn't open. 1 in 128 chance [18:26:42] at first I thought "how could this be broken", haha [18:26:45] hahahaha [18:26:46] awesome [18:27:11] I guess for Mode 1A aborts you are supported to manually open the main chutes anyway [18:27:17] at a specific altitude [18:31:33] hmm, Saturn IB pad abort gives me a CTD when I am a bit away from the Saturn [18:31:38] and the SLA panels open [18:31:41] that can't be right [18:32:36] AlexB_88, must be something with Sat1Abort1 [18:33:01] yeah Im testing that now [18:33:14] I can confirm the SLA panels open with the pad abort [18:33:25] I did not get the CTD however [18:33:34] were you able to debug? [18:33:34] yeah, was in a new line of code [18:33:36] yes [18:33:47] in LC34 code [18:33:52] Saturn class access violation, which is weird [18:35:35] lol I forgot to put an sm present check in Sat1Abort1 timestep [18:35:46] yeah [18:35:52] and I think I know the cause of the CTD [18:35:58] I had done it for the Saturn 5, but forgot the S1B for some reason [18:36:01] Ill fix that [18:36:18] ok [18:37:51] oh fun [18:38:01] the first batch of six Delco books is out for delivery [18:38:04] including Apollo 14 [18:38:16] I may have terrain info for you tomorrow [18:38:40] nice! [18:38:54] the question is [18:38:55] which one [18:38:57] haha [18:39:02] MSC and MIT didn't agree [18:39:10] hehehe [18:39:13] there is a Luminary memor about that [18:39:15] memo* [18:40:11] maybe it's a third completely different one :D [18:40:37] in a way I hope that :D [18:41:44] hahaha [18:46:18] indy91, was the CTD from something in Sat1Abort1 or related to it? [18:46:27] nope [18:46:31] ok [18:46:43] just a bad Saturn pointer, a small bug in my un-commited code [18:47:08] have the SLA issue already fixed locally [18:47:27] I have* [18:47:40] you can PR it, won't interfere with anything from me [18:50:45] ok [18:54:59] PR sent [20:30:03] that was my 1st test haha [20:30:11] of course it was [20:30:30] dont know why thats so important to me lol... [20:30:42] it is a likely time for a pad abort [20:30:48] yeah [20:31:12] haven't expanded it yet, but there is still a small EDS test at T-1:55h [20:31:35] needs some GSE code in the Saturn stages [20:31:50] I did see the lightshow on my late launch scenario yesterday [20:31:54] ah [20:32:14] the Saturn stages need GSE code for the LV lights [20:32:19] then I can do it as in reality [20:32:31] light, 1,2,3,4,5 on. light 1+2, 1+3, 1+4, 1+5 on [20:32:35] and more [20:32:46] automated checkout program [20:33:19] right [20:33:21] if I listen very close to the pad comm audio with Neil I should be able to recover most of the procedure [20:33:33] closely* [20:33:48] and will need some checklist modifications [20:33:57] but there is not much else going on at the time [20:35:26] well have fun doing more pad aborts at T-0. Good night! [21:02:01] books delivered! [21:07:09] nice! [03:15:31] .tell indy91, I just flew my 2nd opportunity TLI scenario again and sure enough, it now detects TLI completion and sequences to the next state correctly. The evasive maneuver pad comes calculates correclty, but at TLI+3hr20m I get a "Thread Started" and then nothing else [03:16:00] AlexB_88, do you know where in these books the terrain model is> [03:16:02] I can't find it [03:16:14] .tell indy91, MissionState 25 SubState 1 MissionPhase 3 EarthRev 3 [03:16:30] hmm good question [03:16:45] what kind of document do you have? [03:18:11] http://www.ibiblio.org/apollo/Documents/A15Delco.pdf [03:25:54] is there a LM padload somewhere in there? [03:28:03] I don't think so [03:34:12] I cant find it either in the Delco Manual [03:34:54] hmmm [03:38:22] SLOPE [03:39:12] 2527,2530,2531,2532,2533 I think [03:39:37] oh, where'd you find that? [03:40:04] those are just the erasable memory locations of the terrain model [03:40:20] oh, yeah [03:40:40] Niklas was hoping the Apollo 14 version of this book would corroborate one or the other versions of the terrain model for that mission [03:40:49] I have the book now, just can't find any terrain data in it :P [03:40:53] right [03:42:38] I did find one section in the 15 document where they had a few certain padloads for the CSM [03:42:43] but nothing on the LM [03:46:56] im off to bed, night! [05:16:41] good evening, indy91 [05:17:25] thewonderidiot, the other Delco manuals have a graph with the data points of the terrain model [05:17:41] not the erasable data [05:17:46] right, but where? haha [05:18:42] let's see... [05:21:38] by the way, I have an NASSP build where the DSKY buttons (except for PRO) are sent to my FPGA, and the DSKY digital panel (and alarm lights controlled by channel 10) are displayed from the FPGA rather than the virtualagc :D [05:22:16] need to handle all of the special cases, but it's a good first step, and demonstrates interactivity with the hardware AGC [05:23:15] awesome [05:23:27] chapter Science [05:23:43] State Vector Extrapolation [05:26:07] hmmmm [05:27:04] oh! [05:27:10] wow I looked at that page [05:27:15] saw the diagram at the top of the page [05:27:20] and totally missed the graph right below it [05:27:21] d'oh [05:27:28] okay one sec, let me grab the 14 book and take a picture [05:27:32] haha [05:28:17] do you have any interest in seeing the same page for 17 too? [05:30:48] sure, but maybe later [05:31:19] https://photos.app.goo.gl/KFFNkzyqa9vJ7JkWA [05:31:22] there's 14 [05:32:19] thanks! [05:34:12] and here's 17: https://photos.app.goo.gl/ZA21sDVsH55p4Aay5 [05:38:38] agrees with the flown terrain model, I think [05:38:55] need to do some calculations later [05:39:17] which doesn't agree with the actual terrain [05:39:35] because MSC didn't believe in it [05:40:19] I'll do a comparison later, have to go now. Cya! [11:39:50] hey [11:41:47] hey Alex [11:42:08] the terrain model in the Delco manual is just a graph, there is no padload in there [11:42:16] Mike and I found it, it's the flown model [11:42:37] which doesn't agree all that well with the actual terrain [11:43:28] oh and I tested my own 2nd TLI opportunity for Apollo 11 [11:43:34] MCC-1 evaluation works [11:43:43] did you try with your launch late in the launch window? [11:46:14] I just added 3 hours to the normal Apollo 11 MCC scenario [11:46:51] no, I mean did you have the failed TLI+3:20h calculation with that? [11:46:57] or a normal launch, 2nd TLI [11:48:05] no it was the 3 hour late launch, 2nd TLI [11:48:20] I just re used a quicksave from that launch, before TLI [11:48:28] ok [11:48:29] can you try if the RTCC MFD also fails to calculate MCC-1 [11:48:41] ill check [11:48:50] because launch on tim, 2nd TLI opportunity works [11:48:56] so I wonder what the problem with the late launch is [11:49:04] it should have updated the TEPHEM for the RTCC [11:49:11] so that can't really be the issue [11:49:35] one thing: I gimbal locked shortly after TLI [11:49:50] and I never recovered it since I just wanted to test the MCC [11:51:20] but I didnt think that would be an issue [11:52:12] ok, so the RTCC MFD fails the calculation unless I update the launch time in the config page [11:52:25] if I do that, then it works [11:52:41] so maybe the MCC is not doing it either [11:53:01] hmm [11:53:39] RTCC_TEPHEM [11:53:41] in the scenario [11:54:19] 40418.688889930556 [11:54:37] 16:32:00 UTC [11:54:45] so updated [11:54:48] yep [11:55:18] then I need to check the scenario and debug the MCC [11:55:30] possible that the MCC-3 evaluation fails [11:55:36] it checks the DV of a free return MCC-3 [11:55:47] that's how it determines if MCC-1/2 need to be done, or not [11:57:10] ok ill send you a scenario [11:57:26] the real RTCC would have tables with numbers and start using updated values of EMP latitude and GET at PC [11:57:34] based on launch azimuth and TLI opportunity [11:57:43] so possible that it just needs a better guess for those [11:58:32] right [12:01:54] https://www.dropbox.com/s/arbwa6tryhibwk8/Apollo%2011%20MCC%20-%20Late%20launch%20test.scn?dl=0 [12:02:08] thanks [12:02:11] that is about 8 minutes before the thread busy [12:02:59] ok [12:04:18] crew dead [12:04:26] surely the gimbal lock didn't do that :D [12:04:36] no suit pressure [12:04:40] well, not much [12:04:44] yeah [12:05:25] well in this particular test I wasnt too worried about following the checklist to the letter :D [12:05:58] so I must've missed something that killed the crew [12:07:04] ah, it was the suit circuit return valve [12:07:15] forgot to open it [12:07:27] it's the MCC-3 DV evaluation [12:07:49] adding an hour to the pericynthion time makes it work [12:08:26] annoying that it needs such a accurate number, I guess the iteration method there is still bad and doesn't converge [12:09:30] I wonder if the MCC-3 test should rather be a flyby with the nominal pericynthion latitude [12:09:35] because is also quite different [12:09:38] because that* [12:10:44] the latitude [12:11:27] I actually found EMP latitudes and PC GETs for Apollo 11 [12:11:35] needle in a haystack situation [12:11:39] only for Apollo 11 though [12:13:10] oh nice [12:14:11] NTRS has it for Apollo 10 as well, but restricted [12:16:25] ok, in the TEPHEM update function of the RTCC [12:16:35] I'll add some logic to update the PC time [12:17:02] if the actual launch is more than halfway through the launch window [12:19:35] hmm [12:19:49] that's not really right [12:20:01] depends more on 1st and 2nd opportunity [12:20:10] I must have gotten very lucky that it work for me [12:23:09] I'm doubting the wisdom of that MCC-3 check [12:23:20] don't think they really did it this way [12:24:09] so I think I'll rather change that [12:24:15] which takes a bit more time and research [12:24:21] so not gonna happen today [12:25:25] oh and I think we are using the wrong flyby altitude for the free return MCCs [12:25:32] they are reference to mean lunar radius [12:25:50] so 60 is too high, should be 58.34 for Apollo 10 and 11 [12:25:50] or you could just tell me to stop flying these very strange missions :D [12:25:57] never :D [12:26:06] that makes about 2 to 2.5 minutes difference [12:26:43] probably helps our missions that arrive late at the Moon [12:27:01] ah right [12:27:19] I think we had already changed that for the later missions [12:28:35] yeah [12:28:45] MCC for 10 and 11 definitely uses 60NM [12:28:57] so when I am back I'll work on that [12:29:10] no more free return MCC-3 test [12:29:25] too late for a DV optimized MCC [12:31:46] I'll have time though, just not development time. So maybe I'll download the Apollo 11 MCC audio to figure out the EDS test exactly, haha [12:38:14] I guess MCC-3 usually is just an option 1 [12:38:36] yeah [12:38:54] but I'm pretty sure they calculated a MCC-3 to determine its DV [12:39:02] and then decide if MCC-1/2 are necessary [12:39:16] but maybe not with option 2 [12:43:56] maybe it could be, calculate MCC-2 to find the nodal coordinates/time, and then use them for the MCC-3 calculation [12:44:56] yeah, quite possible [12:47:06] hmm, THC does not seem to control the CSM thrusters with the CSM still attached to the SIVB [12:47:37] does that even work with the Saturn DAP mode? [12:48:29] hmm not sure, but Id think that the SCS would still control the CSM thrusters (translation as well) [12:49:01] yeah [12:49:23] must be some config issue on your side [12:49:28] if rotations work [12:50:52] yeah [12:50:55] I thought it was [12:51:18] but I tried just separating and then it suddenly worked [12:52:18] rotation worked fine, yes. It was just translation that didnt work when attached to the SIVB [12:52:27] that's very strange [12:52:37] it's all the same thrusters [12:53:49] yeah [12:53:59] works fine for me [12:54:14] hmm [12:54:21] MAN ATT in Rate Cmd [12:54:28] TRANS CONTR power on [12:54:29] even my prelaunch scenarios (-60s) only rotation works [12:54:29] SCS mode [12:54:54] joystick or keyboard? [12:56:04] works on the pad for me [12:56:07] joystick [12:56:29] with keyboard [12:57:21] ok yes on the pad it worked, I just had to do RCS CMD - ON and TRNFR - SM [12:57:26] yeah [12:57:34] you probably used Direct RCS for rotational commands [12:57:39] and normal was deactivated [12:58:46] ah ok it works in my other scenario too now [12:59:02] my fault for not following checklists lol [12:59:42] you did follow the checklists, which involve having the Auto RCS relays off :D [13:00:50] well the checklist MFD did [13:01:30] when I got to insertion I basically did a quick "flow" to reconfigure to orbit, but not following any checklist [13:02:05] not something I normally do, except when I am jsut making a quick test of something [13:02:12] right [13:03:26] but still, isn't Normal RCS normally disabled when attached to the Saturn? [13:04:05] yeah, RCS CMD - Off at T-15min [13:04:16] yeah [13:04:29] so you just forgot that that is normal :D [13:04:37] right [13:04:54] I guess it would be in the APS failed checklist that that would be reconfigured [13:05:05] so that SM RCS can be used to control the SIVB [13:05:33] and the SM RCS hotfire [13:06:12] just trying it now, works pretty good [13:06:57] I guess there must be an IU command to disable the APS [13:08:11] well there is an easy way to do it from the spacecraft [13:09:06] ith the DAP setting? [13:09:10] with* [13:10:23] LV GUID - CMC I meant [13:10:32] but directly the APS, hmm [13:10:48] yeah to simulate a failed APS [13:12:53] I'm pretty sure we talked about this in the past [13:13:01] there was something in the mission rules [13:15:24] ah right [13:15:27] S-IVB burn mode on [13:15:42] that makes the FCC think it should use the J-2 gimballing for pitch and yaw [13:15:54] oh better [13:15:56] FCC power off [13:16:39] will that still allow gimballing for the TLI burn? [13:17:22] yeah, the LVDC normally enables that same thing at TIG [13:17:38] ah ok [13:17:42] the S-IVB burn mode on [13:17:45] not the FCC power off [13:17:49] that is not wired yet [13:18:19] maybe that is a later addition [13:20:54] I think they added the ability to switch the FCC off entirely on Apollo 14 [13:21:08] when they started controlling the S-IVB far into TLC [13:21:47] if I find the right switch selector channel then I will add that [13:21:58] but Apollo 12 mission rules say to enable S-IVB burn mode [13:22:04] ok [13:22:10] that should work [13:22:14] for loss of one APS module [13:22:21] will still try to control in roll [13:22:29] right [13:24:06] IU channels 31 and 74 [13:27:05] The Skylab Backup Saturn V has FCC power off in channels 60 and 61 [13:27:28] channel 60 was something else for Apollo 8, need to make sure that it is safe to add that there [13:27:39] then you will be able to switch off the FCC entirely [13:27:55] oh, and speaking of these IU commands [13:28:11] in the Apollo 11 checklist they apparently have the LV light no. 1 on after TLI until CSM sep [13:28:20] neither Apollo 10 or 12 have that, quite strange [13:28:32] for Apollo 11 I don't have the exact flight sequence [13:32:17] interesting [13:34:03] normally the light is turned off at TB7+10 [13:35:34] they mention it in the transcript [13:35:45] so it can't just be a weird checklist thing [13:39:19] yeah [13:39:22] btw found something interesting in the Apollo 12 flight journal [13:39:38] "002:25:41 Gordon: And Houston, if you're not going to use the computer, I'd like to go ahead and put in the Timebase 6 program that we have in our erasable, just to watch it." [13:40:10] oh, nice [13:40:16] and then in the Apollo 12 back up TLI procedure, there is a procedure I think for that [13:40:17] didn't think they would have used it [13:40:22] I wonder if its related to that [13:40:35] related to what? [13:40:54] oh the TB6 program with the thing in the checklist? [13:40:54] yes [13:41:01] we have the padload for the TB6 program [13:41:02] if what he said is related to the procedure in the back up TLI checklist [13:41:07] yeah [13:41:11] definitely [13:41:25] Mike and I figured out how to make it work in Comanche055 [13:41:32] oh nice [13:41:44] but Apollo 11 didn't have that TB6 program yet [13:42:14] lets the CMC start TB6 [13:42:25] as P15 later [13:44:03] but I had no idea they would actually use it [13:44:20] don't think it can actually do anything with the LV GUID switch in IU [13:44:25] right [13:44:27] so they just run it for fun [13:45:41] I guess even if there was a guidance failure, and they had to do a backup TLI, that program initiating TB6 is still then a backup because I think the LVDC would still command TB6 [13:46:29] kind of [13:46:59] I guess the CMC command would be a second, redundant signal? [13:47:43] yeah, I think you are right [13:48:02] it allows the LVDC to also start TB6 [13:48:32] not sure how it is made sure that the LVDC doesn't give a wrong TB6 signal [13:48:41] maybe our LVDC logic is missing something for that [13:48:51] but this line of code is optional, redundant signal [13:48:52] if (lvda.GetCMCSIVBIgnitionSequenceStart() && GuidanceReferenceFailure && LVDC_Timebase == 5 && LVDC_TB_ETime > 100.0) [13:49:49] but a GRF should inhibit the normal TB6 logic [13:49:54] which I don't think is currently done [13:50:38] one thing though, is the Apollo 11 checklist does not have a CMC procedure for timebase 6 in the backup TLI checklist [13:50:55] so that leads me to beleive they still relied on the LVDC for that [13:50:59] believe* [13:51:10] yeah, as I said, "but Apollo 11 didn't have that TB6 program yet" [13:51:15] we have the padload for 11 [13:51:18] no TB6 program [13:51:22] right [13:51:35] the one for 12 and 13 is basically identical iirc [13:51:43] for Apollo 14 they added an extended verb [13:51:51] so basically already P15 in all but the name [13:52:57] so in the case of a backup TLI on Apollo 11 I am thinking that they must've let the LVDC start timebase 6, or use the manual TB6 procedure in the CMC (not the EMP I mean) the V1N10 etc [13:53:28] but that procedure is not found in the 11 checklist so I dont know [13:53:44] hmm [13:54:27] in other words there is nothing in the 11 checklist that details how to command TB6 from the cockpit, so there mustve been something else [13:54:49] either rely on the LVDC or ground command? [13:55:13] but I am thinking if the LVDC still had a good SV it should be able to do it [13:55:57] IU state vector update for a GRF [13:56:07] and then it can start TB6 [13:56:15] yeah that makes sense [13:56:17] if there only is a LV IMU issue [13:56:27] LVDC gone completely, no TLI I would guess [13:56:33] that basically works right now in NASSP [13:56:39] but we only simulate the 1st case [13:57:01] LV IMU gone [14:01:58] I guess if they actually lost the whole LVDC, then the ground could give them the manual TB6 procedure [14:02:54] hmm [14:02:58] I'm not so sure [14:03:15] for Apollo 9s third S-IVB burn they uplinked basically a whole ignition sequence [14:03:20] but those signals still go through the LVDC [14:03:37] if it can't do that, then you can't do anything with the S-IVB [14:06:15] right [14:07:02] I forget the LVDC does more then just guidance [14:08:27] yeah, it sends out all the timebase relative commands [14:08:35] to the stages [14:09:00] I think it would be pretty unlikely to lose the whole LVDC [14:09:15] losing the IMU sounds more likely to me [14:09:31] yeah [14:10:05] which is probably what this backup TLI procedure is mostly geared towards [14:10:48] it tells the LVDC to start TB6 [14:10:57] right [14:11:01] and the LVDC then does all the things necessary for the restart [14:11:17] well Apollo 12 and later [14:11:54] yes [14:12:09] this was probably not wired yet on 11 and earlier [14:12:36] Apollo 11 has no CMC procedure, but they probably just relied on the LVDC (with an updated SV) to start it [14:12:38] right [14:13:13] it does work in NASSP with Apollo 11, if you do the manual TB6 procedure in the CMC, but maybe that should not work [14:13:57] like you say maybe the LVDC wasnt wired to monitor the output from the CMC until Apollo 12 [14:21:42] yeah, I think that's the case [14:31:49] ok, I have to go now [14:31:59] cya on Tuesday at the latest! [16:43:21] morning! [16:55:25] hey Mike [18:37:00] any more luck with NASSP and the AGC? [22:44:35] AlexB_88: I have the DSKY mostly there [22:44:40] still need to implement PRO and the non-latching lights [22:44:55] but the DSKY displayed in my NASSP build is from my FPGA, not the virtualagc [22:45:39] ah nice [22:46:00] btw I have a favor to ask [22:46:04] sure! [22:46:05] https://www.orbiter-forum.com/showthread.php?t=40808 [22:46:28] this is a workaround to permit long duration lunar missions [22:46:34] could you sticky that? [22:47:05] done! [22:47:12] awesome! [22:47:16] thanks [22:47:29] sure thing :) [18:22:29] morning! [18:25:13] good evening [18:25:15] hey [18:25:50] last night I was listening to the BOOSTER loop [18:25:59] then I fell asleep [18:26:29] and I woke up to Spiro Agnew talking about going to Mars [18:26:46] in LCC, after the launch [18:26:49] hahaha [18:26:59] was just a bit confusing:D [18:27:16] hehehe yeah [18:27:36] a strange thing to wake up to :D [18:27:45] indeed [18:28:14] hey [18:28:35] hey Alex [18:28:55] trying a manual TLI with Apollo 15 [18:29:16] Im sure P15 is better at cutoffs then my finger on the SII stage switch [18:29:37] is that on VI as well? [18:30:46] then it would still depend on the TLI PAD having a correct value for that, which I am not that sure about [18:31:02] VI [18:31:14] I am using the manual charts VI [18:31:26] ah [18:31:31] thats what works best for manual TLIs in my tests [18:31:42] is TLI PAD VI high again? [18:32:52] 35646 for 15 [18:33:24] 35599 is whats listed on the nominal TLI 1 card [18:34:40] 35646 is what the RTCC MFD shows* [18:35:49] mind you, this is a slightly old scenario, maybe a year old or so [18:36:45] partially that will be the TLI PAD not accounting for the velocity increase after cutoff signal [18:37:10] if the scenario is older it might not do the MRS on time yet [18:38:02] so that could also make the VI different [18:38:31] TLI PAD calculation is based on whatever is in the LVDC [18:39:04] so the MRS time as it will actually happen [18:39:31] but it's not really simulating the TLI yet [18:40:36] I'll implement that some time, like I did for lunar ascent/descent for the abort coefficients [18:41:08] should make TLI PAD numbers more accurate [18:45:16] so I'm making good progress with NASSP -- the DSKY is fully implemented now, scenario loading correctly initializes AGC erasable, and I made SetErasable() forward data in to the AGC... so it's coming up correctly in the scenario now and getting ICDU data [18:45:31] need to figure out the input channels next [18:46:35] some are written each timestep, some aren't [18:47:16] maybe you want a buffer of those Channels and connect it to the AGC [18:47:45] yeah, the monitor is going to create channels 70-74 [18:47:59] and whenever NASSP updates 30-34, latch that into those channels [18:48:07] and then it will force the AGC to read from 70-74 instead of 30-34 [18:48:20] after all it is just switch closures of circuits coming from and going back to the AGC [18:49:00] right [18:49:23] so far this is even easier than I was thinking it would be :D [18:49:36] does PIPA data go through SetErasable() as well? [18:50:44] hmm, no, it forces counts [18:50:55] that's going to be harder [18:50:59] MINC and PINC [18:51:07] I think [18:51:11] yeah [18:51:39] alright good TLI, MCC-1 is 118 fps [18:51:41] hmmmm [18:53:03] eating into your LM rescue budget, Alex :D [18:53:49] at least the J-type missions didn't want to spent more than 100 fps during the TLC [18:54:10] Ill just drop a shape burn or 2 :D [18:55:27] thewonderidiot, isn't that more realistic how we do the PIPAs? [18:55:36] yes, but I can't inject counts through the monitor [18:55:45] that makes it harder? [18:55:46] so it makes it a lot harder for this way [18:55:48] ah [18:56:12] do you think it would work if I just injected the number straight into the PIPA counter erasables? [18:56:18] or does it need to be additive? [18:56:20] can probably changed in our IMU code [18:56:36] not sure [18:56:47] only one way to find out I guess :P [18:56:56] that's one of the things I never had to mess with [18:57:46] my main contribution to the IMU code is the IMU Temp input bit [18:57:58] I am pretty surprised on how accurate manual TLIs can be, even 118 fps [18:57:59] hehehe [18:58:17] yeah, that's quite good [18:58:50] But you really need to have the TLI procedure of the exact mission your flying [18:58:51] and that still has you arrive at the Moon at the nominal time? [18:59:35] well option 4 I think uses constant TOA solutions [18:59:43] if I am not mistaken [18:59:44] yes [19:00:05] which is what I used for the MCC-1 calculation [19:00:37] let's see if my build of NASSP can still run with virtualagc... [19:00:40] so it could be DV optimised even more [19:01:02] haha [19:01:05] Each mission seems to have a slightly different backup TLI procedure, the time you start the ORDEAL torquing I think is dependent on the specific missions trajectory [19:01:24] right [19:01:52] will depend on the desired ignition attitude [19:02:11] thankfully we have the backup TLI procedure of most missions [19:02:18] most that had one [19:02:27] I think only 13 and 17 is missing [19:03:05] what does the AFJ have for 17? [19:03:17] 13 is certainly missing [19:04:57] ah [19:05:11] Systems and Entry checklists [19:05:16] no Launch [19:12:22] what's OHW in the checklists? [19:12:27] ooh lots of Apollo 17 docs at JSC [19:12:31] when it says OHW < 34 degrees [19:13:36] overhead window [19:13:45] I think [19:13:59] SPACECRAFT operational trajectory FOR APOLLO 15 ( MISSION J-1 ) LAUNCHED JULY 26 1971 VOLUME I - MISSION PROFILE [19:14:12] do we have that one? [19:14:23] not sure. [19:14:39] I'm sure I requested it [19:14:58] maybe they didn't actually have it, have to check [19:15:24] but yeah, the JSC History Collection has lots od [19:15:35] of late Apollo and ASTP checklists [19:16:25] yeah [19:16:38] waiting to be requested. Have ever done that in the post Lauren eta? [19:16:48] we* [19:16:58] era* [19:16:58] not yet [19:17:53] yeah [19:18:19] good night! [19:19:08] coming up on PDI with SetErasable instead of counts for PIPAs [19:19:34] oooh [19:19:44] running with virtualagc [19:19:47] to see what happens :P [19:20:04] I predict a V97 [19:20:22] or it might just work [19:20:23] don't say that, haha [19:20:27] old forum mo [19:20:41] might have the answer to that [19:21:01] damnit [19:21:03] flashing 97 [19:21:52] sorry [19:22:24] I guess I need to watch how the counters normally behave [19:24:02] hmm [19:24:43] I'm guessing it zeroes them once per servicer cycle [19:24:50] and in between then they integrate [19:24:51] ah [19:25:15] so, how to do that... [19:25:25] hey, better than the AEA doing exactly that every 20ms [19:25:30] heh [19:25:59] uh oh [19:26:00] what happened [19:26:07] I'm scooting across the surface suddenly, haha [19:26:49] doesn't sound healthy [19:28:02] so what I probably need to do is have a mirror of the pipa counters in the monitor [19:28:18] and add counts onto that, and write the integrated value into the AGC [19:28:28] and when the AGC zeroes the counters, also zero my copy [19:29:48] I think it's doable, will just need a bit of work [19:30:31] in this NASSP is doing it right and you need it less realistic :D [19:30:39] yeah, yeah [19:30:41] case* [19:30:48] lol [19:31:19] if I was making a real PIPA simulator the right way would be better [19:31:38] but for now I want it to go strictly through the test connector so [19:31:58] gotta do what ya gotta do :D [19:32:18] NASSP is going to continue doing it right, for what it's worth, I just need to make the monitor smarter [19:32:40] so let's see... I made a checklist [19:32:46] already seems quite smart to me, haha [19:33:09] DSKY, scenario loading, CDU counts, RNRAD, output channels should all work [19:33:22] I'm making the FPGA changes for PIPA counts and input channels now [19:33:43] and then the last thing I should really need is THRUST, right? and I'll also get ALTM readouts going [19:33:53] am I missing anything? for just a P65 landing? [19:36:02] don't think so [19:36:24] sweet [19:36:29] getting close :D [19:36:53] maybe today or tomorrow I'll have a hardware AGC performing a landing [19:37:03] you don't need the tape meter and cross pointers [19:37:19] yeah, those are just nice-to-have [19:37:43] ICDU error counter stuff [19:37:55] also more nice to have [19:37:59] that's not needed unless I'm doing an alignment, right? [19:38:13] or steering a Saturn [19:38:16] hehehe [19:39:04] only LR control is output bits [19:39:36] RCS should be just fine [19:41:02] oh, how would you like a Zerlina landing scenario? in the unlikely case you need to impress Don [19:41:35] hahaha sure! I mean, Don is going to be at the brunch [19:42:41] I can give you one next week [19:43:11] or any flown mission [19:43:11] even Apollo 10 [19:43:17] awesome, thanks :D [19:43:44] an Apollo 15 scenario would be good to have, too [19:43:59] since that one is the most spectacular [19:44:06] yeah [19:44:39] Apollo 17 being a close second, landing in a valley and all [19:45:07] yeah for sure [19:45:39] nothing beats flying over the tallest mountains of the Moon and then landing next to a rille [19:46:28] next time they do that they should take a drone with them for the outside views :D [19:46:35] hehehe [19:46:40] or put more windows in :P [19:47:50] yeah, facing down [19:48:07] a window would have been great right where that pesky LGC is [20:01:36] and much needed if there was no LGC there [20:02:45] night! [17:20:44] morning! [17:22:45] lots of progress yesterday. the input and output channels are wired up (except for channel 32, which somehow breaks PDI calculations), and the FPGA is now controlling its attitude pretty well and turns on the engine at 10% when it's supposed to [17:24:14] hey [17:24:28] got home two days earlier than I thought, yay [17:24:44] good progress [17:25:36] channel 32 is a weird one to cause issues [17:26:09] yeah. it makes the velocity at T-30s become 99918 instead of 55669 [17:26:14] and I can't figure out why [17:26:33] but I looked over the bits and it looooks like I can get away with just not using that channel for now [17:26:38] PRO key, gimbal fail, gimbal off, thruster failures [17:26:44] it seems like the only critical thing in it is PRO [17:26:50] yeah [17:26:54] all 1s there should be safe [17:27:02] cool [17:27:10] I'll debug it later then :D [17:27:26] unless you have all zeros for the thruster failures, maybe that breaks the DAP [17:27:28] it's probably detecting and corrupting some instruction it shouldn't be [17:27:35] yeah, maybe [17:29:52] getting close though! just need to ponder how to how to do the PIPA logic [17:31:35] have you taken the Virtual AGC out of the loop yet? [17:31:56] oh yes, that was the first thing I did [17:32:13] I made agcTimestep() only actually run virtualagc if the monitor isn't attached to the FPGA [17:32:34] ah, good [17:32:46] then you won't even need to disable ApolloGuidance::SetOutputChannel [17:33:01] yeah, I can use it for my own output channels :) [17:33:25] RIP telemetry though, haha [17:34:26] haha, what do you mean? [17:34:55] in LEMcomputer::agcTimestep [17:35:00] lem->VHF.Timestep(ThisTime); [17:35:10] this calls downlink [17:35:13] PCM [17:35:20] aha [17:35:34] needs to be in sync with the AGC, so it's called in the AGC timestep [17:35:39] hmm [17:35:55] sounds like a problem for future Mike [17:36:55] yeah [17:42:36] another thing I need to figure out is that my function to inject erasable commands doesn't work well if I don't have the AGC halted [17:42:52] I only have to halt it for a couple of MCTs [17:43:06] but if I don't, the AGC will randomly restart and the attitude control is *very* bad [17:43:14] or at leat [17:43:21] at least [17:43:26] it will hold an attitude [17:43:39] but it burns through RCS like crazy trying to do it, and will have a lot of excursions [17:44:31] and during one run I almost made it to PDI but just a couple minutes before it decided to turn on two RCS thrusters and leave them on until I was out of RCS propellant [17:44:39] ouch [17:44:45] it was going for spin stabilization I think :P [18:04:30] okay, I think this shouldn't be too bad. I just need to tweak my erasable memory simulator to provide signals to the rest of the monitor FPGA about when erasable cycles are happening and against what address [18:04:45] and have it grab values written to the PIPAs [18:05:06] and then make a one's complement adder to incorporate incoming pulses from NASSP onto that value [18:08:40] doesn't seem so bad [20:12:46] oookay, I think I might have all of that implemented [20:12:52] now to test before hooking it up to NASSP [20:13:23] if this works, then I'll get past V97 [20:13:29] and I thiiiiink should only have to wire up THRUST [20:13:39] awesome [20:14:08] how do you do thrust now? Or are you not testing past TIG+26 seconds? [20:14:42] haven't made it that far yet :D [20:15:14] I see [20:15:27] THRUST should be pretty easy after PIPAs [20:15:30] I have all the tools I need now [20:16:39] I just need to detect when it's written to outside of a count, and present that number to NASSP as channel 142 [20:42:51] lol [20:42:54] well that doesn't quite work [20:43:08] damn [20:43:18] clearly I have a logic error somewhere [20:43:29] I'm affecting the PIPA registers, but not getting the numbers I want [20:44:18] scaling? [20:44:52] nah, probably my one's complement adder is broken or something [20:45:13] this is before scaling, I'm just working in raw counts at the moment [20:45:37] hmmm [20:49:16] initial value in the PIPA registers causing anything? [20:49:31] I don't know much about them, but I was surprised to see them not nulled until Average G starts [20:50:41] and what are the numbers you currently want to see? [20:54:59] I've just added a couple of buttons to the monitor panel to cause a single + count and a single - count [20:55:09] so I'm expecting to see the registers change by one when I click the buttons [20:55:15] I just figured out one of my problems [20:55:34] not accounting for the double sign bit [20:56:39] anything the software does? [20:57:07] what do you mean? [20:57:24] software messing with the counter [20:57:40] or is this not even interacting with the AGC yet [20:59:39] ah, no, I have the AGC running [20:59:52] but it's just sitting idle starting from all-zero memory [20:59:59] and doesn't appear to be messing with the PIPA counters [21:00:16] good [21:03:19] hmmm [21:03:44] okay, first problem solved [21:04:01] second problem is that I don't appear to actually be detecting AGC write cycles against the counters [21:04:15] so when I click the button, it's only adding against my initial value of 0 [21:06:21] ah [21:06:23] dumb bug [21:08:13] was only piping the target address through to the NASSP bridge logic if an erasable memory simulation cycle was active [21:09:21] good that you found it [21:09:25] good night! [21:16:27] it works!! [21:17:29] gonna grab a quick lunch and test with NASSP [21:17:34] I'm feeling a landing today :D [07:16:02] .tell indy91 I'm *so close* -- everything is wired up now, and throttle up happens correctly at 26s [07:16:48] .tell indy91 but I get an early throttle down at +3m, which took me a bit to trace down but it appears that calculations are also being somewhat corrupted by channel 30 simulation. that's less ignorable than 32 so I need to root cause this [07:17:11] .tell indy91 but the problem is escaping me at the moment, I can't figure out how this could be corrupting calculations [07:42:38] .tell indy91 oooooh nevermind I think I just found a case where EXTEND...INDEX can be interpreted as an I/O instruction, so I might mess something up if the variable being indexed contains the values 070, 071, 072, or 073 [07:44:45] .tell indy91 or rather, 030 through 033, which makes a little more sense [08:20:00] .tell indy91 THAT WAS IT! throttle down on time, but it's mad about the radar and is flashing VEL at me. I just did an attempt and it's taken me down to a place where I could totally P66 it down softly if I had a hand controller wired in... but P65 can't figure out how high it is so it's just hovering and is going to deplete my fuel [08:48:38] .tell indy91 that was because the RR logic was calling GetInputChannel() for channels 12 and 13, which is something I hadn't anticipated. I made the bridge code cache those output channels and made apolloguidance grab them from the bridge on request... and SOFT LANDING! :D [12:40:45] . [13:48:08] hey [13:50:48] hey Alexc [13:50:51] Alex* [13:53:09] seems like Mike got landings working controlled by his FPGA [13:57:25] nice [13:57:38] any videos? [13:58:28] he managed to do it just last night, so nothing yet I guess [13:58:42] and with the real AGC it will be the next time they come together to work on it [14:04:20] provided he manages to get that to work [14:04:46] but it seems with various workarounds NASSP is compatible with it [14:08:30] right [14:13:48] so I was testing the TLI inhibit functionality last night, works quite good. One thing I saw in the Apollo 15 TLI checklist is that before 59:42 in TB6, the xlunar inject switch can inhibit TLI, after that time and until 00:12 the SII/SIVB switch can be used to recycle to TB5, and then after 00:12 its permanently inhibited [14:14:54] I dont think it works that way with the SII/SIVB sep switch right now in NASSP (just goes straight to TB7) but I guess that is the correct pre-Apollo 15 functionality? [14:15:26] that is the correct Apollo 15 functionality, haha [14:15:48] definitely not Apollo 8 [14:15:53] probably not until 14 ot 15 [14:16:09] or* [14:16:14] yeah [14:19:34] a change for Apollo 14 sounds like this functionality [14:25:10] event timer 00:00 is TB+578 [14:25:35] we use the Apollo 8 time for the latest possible time to go back to TB5 [14:25:46] which is TB6+560.0 [14:25:56] after that TLI inhibit is ignored [14:26:07] and after ignition any cutoff signal will make it go to TB7 [14:26:56] that is also how it worked up to Apollo 12 [14:27:15] and very likely Apollo 13 [14:29:17] makess sense [14:29:31] and TLI inhibit is still only read up to TB6+560 (59:42 on the ET) for later missions [14:30:02] new capability added on Apollo 14 is an additional way to get into TB6C [14:30:15] TB6C is the timebase used for TLI inhibits [14:31:17] it now looks for S-IVB engine out signals from TB6+584 (00:06) to TB6+590 (00:12) [14:32:15] our TB6 sequencing logic is already very complicated, not looking forward to implementing this to be truthful, haha [14:32:58] not easy stuff I bet haha [14:33:09] yeah [14:33:18] and this is probably already after IGM has been started [14:33:28] so maybe some of the IGM settings need to be reset [14:33:48] I think the Apollo 8-13 functionality is fine for now [14:33:55] which wouldn't be super difficult, that would be in the code that switches to the parameters for the 2nd TLI attempt [14:34:19] yeah, I think I'll keep it as it is right now [14:34:31] but stopping TLI after the engine has already started sounds fun [14:34:37] and it still allows for a second attempt [14:35:20] yeah [14:35:48] I guess you have a slightly elliptical orbit if you stop it right before the limit (00:12) [14:36:22] yeah [14:36:39] shouldn't hurt the restart calculations too much [14:42:02] the last few pages of each Saturn flight evaluation report has changes to the Saturn stages, including the IU and the LVDC flight program. Really good resource to look up the version differences. [14:43:13] other than the AGC the LVDC flight program still got updates after Apollo 15 [14:43:48] yeah I guess they got updates every mission [14:44:12] pretty much [14:44:25] "Attitude command rate limit changed to 0.14 degrees/sec in TB5" [14:44:34] how does it even reach LVLH attitude then, haha [14:44:39] after insertion [14:44:42] that must take ages [14:46:18] hmm, only about 2 minutes [14:46:42] still slower than we get I guess [14:46:48] that was a change for Apollo 16 [14:47:24] must take ages to get to restart attitude during a manual TLI [14:48:04] TB5 only [14:48:18] TB6 is 1°/s in each axis I think [14:48:31] right [14:48:35] and that is only for the LVDC attitude commands anyway [14:49:34] .3/s I think for TLI [14:49:51] oh only for LVDC commands [14:50:44] yeah [14:51:00] the CMC uses the same settings as normal TB5 I believe [14:51:10] 0.3°/s in pitch and yaw, 0.5°/s in roll [14:58:14] latest AGC restoration video: https://www.youtube.com/watch?v=2qe4W_USweE [14:58:50] the filler episode, while Mike was still thinking a 210 alarm might be from a missing PIPA simulation and not just a missing input bit [14:59:35] nice [15:00:49] I have to run, Ill be heading down to Florida tomorrow for a week. I wont be on much but I may drop by the chat with my phone. Have a good week! [15:01:00] cya! [15:01:07] cya! [16:46:03] morning! [16:50:06] hey [16:50:35] what's up? [16:51:44] just restructuring some code [16:51:51] good job on getting the landing working [16:52:07] thanks :D [16:52:14] I stayed up waaaaay too late last night [16:52:29] but once I saw the problem in the waveforms while laying in bed I couldn't help myself :P [16:52:56] haha, I know the feeling [16:53:13] I'm going to implement the tape meters tonight, since it looks like the logic should be identical to THRUST [16:53:32] and then I'll record a video so you can watch it and tell me how bad my trajectory is :D [16:54:11] why would the trajectory be bad? [16:54:37] I got enough of a pitch down in P63 to see the surface, and it was another minute or so before P64 actually started, which had me worried [16:54:44] and throttle down was ~25s early [16:55:24] hmm [16:55:25] but I think maybe a part of this was that I've been doing my tests entirely heads-down in PDI, up until the point at TIG+5:45 or so when the AGC gets annoyed and rolls the LM over [16:55:42] partially because I don't have the hand controller set up, and partially because it's fun to watch the AGC do such a dramatic maneuver [16:55:46] right, so LR data pretty late [16:55:48] yeah [16:56:18] I'll prepare a heads up scenario tonight to see how much of a difference it makes [16:56:18] well possible that that changes the trajectory quite a bit [16:56:31] DH seems to be 3000 ft for that scenario [16:56:45] yep [16:57:01] you could probably reset the flag early that forces the LM heads up :D [16:57:10] hahaha [16:57:18] oh! that was another problem I had that you might be interested in [16:58:10] BIT 9 FLAG 11 has to be set for that I think [16:58:38] I started to get a huge number of endless 511 alarms right when AVERAGEG starts at T-30s [16:59:38] and it turns out that it's because of a flaw (?) in restart protection. because of how the hardware works I can't just resume execution mid-program, I have to load the AGC state and then force a hardware restart so it picks up correctly [16:59:56] interesting [17:00:00] but if you take a restart on the auto maneuver screen (which is where that scenario loads you), the RADMODES flagword gets messed up [17:00:33] my incredibly dumb fix is to use V69 to force another hardware restart on the next screen [17:00:41] which takes RADMODES back to its proper value [17:00:59] Luminary099 is especially buggy when it comes to RADMODES anyway [17:01:05] right, I remember that causing problems [17:02:24] what else... [17:02:31] my first implementation of THRUST wasn't quite smart enough [17:03:19] my original logic was to watch for the AGC to write to the THRUST register, and then if after that it writes a 1 to the right bit in channel 14, then send the value that was last written to NASSP [17:03:44] which worked fine for throttle up, but at throttle down the throttle ended up seeking all over the place [17:04:25] turns out, the AGC does other things with channel 14 while THRUST is counting out, using instructions like WOR that the monitor interprets as also setting the bit [17:05:30] so I have to have another layer of protection, such that my value for THRUST is only updated when it occurs outside of a count, and I only send it to NASSP the very first time the channel 14 bit is set to 1 after the AGC has written to THRUST [17:06:18] that's weird [17:06:23] double using the bit like that [17:07:09] it's using other bits, but the WOR instruction operates by reading in a channel, changing some (different) bits, and then writing it back out [17:07:30] ah, of course [17:07:56] to the monitor, which is operating at the control pulse level, I only see the "write" part of the WOR, so it looks like that bit is being set to 1 again -- but it's not really, it's just that it was already 1 while THRUST is still counting [17:08:19] right [17:08:41] I'm sure the DECA had fun with those additional thrust commands :D [17:08:50] haha yeah [17:08:56] the throttle went all over the place [17:09:07] P66 but worse [17:09:11] although (by accident probably) it did eventually settle in to the 50%-ish range [17:10:54] better switch to manual throttle with that :D [17:10:59] hehe yeah [17:12:35] so I guess after altitude meters, barring any other changes that need to be made, the hand controller would be the next thing to add [17:12:40] although that one will be very complicated [17:13:28] yeah, I can imagine [17:13:36] when you were thinking about feeding back a LGC calculated throttle setting to the PIPAs I first thought that Luminary210 had some smarter logic, because it has a manual throttle setting display in a noun [17:13:53] oh interesting [17:13:54] but that is really just the magnitude of the desired thrust before much processing [17:13:59] so it starts at beyond 100% [17:14:01] heh [17:14:04] right [17:14:07] and doesn't avoid the rough combustion area of 60-90% [17:14:15] so not useful [17:14:23] not without an astronaut [17:14:28] yeah [17:14:37] just going through NASSP is definitely the right way to do this [17:15:06] yeah [17:15:09] and now that all of the pieces work through the monitor, we can break them out one by one to go through the proper interfaces [17:15:17] and didn't seem super complicated after all [17:15:25] yeah, it wasn't that bad [17:16:04] I got it working a *lot* faster than I was thinking originally [17:16:15] so that is the setup you are planning to demo the AGC with? [17:16:40] I'm just thinking about all the annoying things NASSP could do to screw that up, haha [17:16:43] I'll have to run it past the others, but it's going to be hard to not show off a landing [17:16:44] hehehe [17:17:04] well, the first annoying thing that I need to figure out is how to get a good enough framerate on my laptop [17:17:14] since my desktop won't be able to go to boston with me [17:17:15] delete the CSM? [17:17:21] oh that's a good idea [17:17:30] and S-IVB, although that's probably not going to much of a problem [17:17:48] deleting the CSM should be safe. Probably. Maybe. [17:17:55] lol [17:18:12] RR interacts with the CSM, but it has a check if it even exists [17:18:15] I might also kill the AGS, now that I think about it, since I don't really need to show off anything with it [17:18:31] LM panels are fairly light in terms of performance [17:18:35] and by AGS I mean AEA [17:18:36] FDAIs in general are not [17:18:41] hmm [17:18:48] definitely don't use smooth scrolling in the NASSP settings [17:19:03] but even without it's a bit of a drag of performance [17:19:16] but no CSM and AEA should already help a lot [17:19:20] okay [17:19:26] yeah, I'll have to play around with it [17:20:00] we just use a lot of outdated graphics tech [17:20:19] I also need to get a scenario set up. I think I want one that starts just a few minutes before PDI, but doesn't yet have P63 running, so I can do the V37 [17:20:20] and in general having so many simulated and emulated parts will be mainly CPU bound [17:20:29] sure [17:20:44] you can just do a quicksave and start using that [17:21:01] and I'm kind of torn between flying heads down through the braking burn, for the lunar visuals and the dramatic maneuver, or flying heads up for the accuracy and better trajectory [17:21:13] yeah [17:21:23] it's annoying that it's not really automatic [17:21:35] with the late yaw to heads up [17:21:41] yeah [17:21:57] Apollo 12-17 all flew heads up [17:22:15] and 11 even, right? they yawed a few minutes before PDI? [17:22:45] no, into PDI [17:22:52] ohhhhhh interesting [17:23:01] Neil already knew they were long that way [17:23:06] looked at timing and crater I think [17:23:09] right [17:23:37] is the time for the yaw (or altitude/velocity/etc.) hardcoded, or is it controlled by some erasable that controls it? [17:24:15] it's a DAP flag [17:24:20] reset at 30,000 feet [17:24:23] altitude [17:24:31] by some P63 routine [17:24:43] X-axis override is the flag [17:24:56] let's you freely yaw around under many circumstances [17:25:41] manual yaw was at PDI + 3:30 [17:26:09] pretty sure it should be BIT 9 FLAG 11 [17:26:23] and it will be SET by the software at 30k feet [17:26:52] there is also BIT 9 FLAG 13 which is related, not quite sure [17:27:04] found the code, yeah [17:27:16] ALTCHK has a table for altitudes being checked [17:27:47] yeah, makes sense [17:27:48] option 6 is 30,000 feet, and is when SERVICER sets XOVINFLG [17:27:54] even for LR VEL data [17:28:00] which was later changed [17:28:21] in Luminary099 it wasn't checked until a specific altitude [17:28:51] okay well... assuming I continue to get decent soft landings, and assuming I don't get the hand controller working, I'll probably just let it do its automatic 30,000ft yaw [17:29:34] no I was wrong [17:29:37] that's below 2000 ft/s [17:29:42] not altitude [17:29:54] V > 2000 FT/SEC DO NOT READ VEL [17:30:21] that will give you late LR data of course and might affect the trajectory more than it should [17:30:39] what do you mean? [17:31:05] the automatic yaw maneuver will be some time later than the manual one [17:31:11] so LR lock-on will also be later [17:31:17] LR pointing into space doesn't help much [17:31:24] right [17:31:34] and I think there is a decently large altitude error in that scenario [17:31:50] for some reason, most of it is elevation uncertainty of the landing site [17:32:07] from before mission [17:32:19] that is why the CSM was doing landmark tracking to refine that [17:32:30] easier to figure out when you are close by than from Earth [17:32:41] but the altitude error in the scenario is in line with what it was during the real mission? [17:33:04] 102:38:11 Aldrin: Yeah. Altitude light's out. (Pause) Delta-H is minus 2,900. [17:33:13] so a little bit more, but not much more [17:33:22] not sure if it is in the same direction though, haha [17:33:34] hahaha [17:33:36] our error will be due to that landing site uncertainty [17:33:47] and the real one due to mascons and what not [17:33:51] right [17:33:56] and their general SV accuracy issue [17:34:14] but if that error is taken out late, then it has an effect on the trajectory [17:34:23] so with a late V57E [17:35:05] so if yaw to heads up is late, LR data incorporation is late [17:35:21] and 3000 feet isn't nothing if you are at 30k feet and heading down quickly [17:35:48] I don't know, I'll have to watch your video of a landing to see [17:36:09] hahaha alright [17:36:23] I'll have it for you tomorrow [17:36:56] I'm expecting from what I saw that you will say that I definitely need to set up a hand controller and do the yaw at 3:30 :P [17:37:04] throttle down being early is new to me though, haha [17:37:22] until recently we were always getting late ones [17:37:34] DPS parameters being off [17:37:39] now it's closer [17:38:16] I forgot which scenario you are using [17:38:44] the standard NASSP Apollo 11 Pre PDI scenario? [17:38:45] Mission Scenarios / Apollo 11 / Apollo 11 - 12 - Pre-PDI - T+102... [17:38:46] yeah [17:38:55] ok, that is at least mostly up-to-date [17:39:13] better than the one you were trying on your FPGA in that one AGC restoration video [17:39:28] lol [17:39:30] that was from a core file, very old NASSP scenario [17:39:51] hahaha [17:39:58] oh I didn't realize that one was older [17:40:32] that was from the very first Virtual AGC lunar landing in NASSP [17:40:39] oh wow [17:41:21] yeah I could see how that would be quite outdated :D [17:41:30] might even have padload bugs [17:41:35] we've come quite far since then [17:41:36] definitely think a few things should be changed in the scenario you are using [17:41:40] MCC definitely can be disabled [17:42:03] oh, how hard is it to disable the voiceovers? [17:42:19] and for the timing, you could just V37E 00E out of P63, wait until the right time, save and use that [17:42:30] the voice over at landing? [17:42:45] I'd like to keep the LM sounds but the voice clips randomly playing will be annoying when giving a talk, haha [17:42:51] oh those [17:42:55] I always have them disabled [17:42:58] that's from Orbiter Sound [17:43:08] SoundConfig.exe in your Orbiter folder [17:43:17] ah cool, so there's an option for it [17:43:35] "Allow ATC Sound" option on the right side of that [17:44:01] I think that's all from STS-114, or 115 [17:44:01] perfect, thanks [17:44:05] heh [17:44:18] or 121 [17:44:35] not particularly applicable to a LM then [17:44:38] yep :D [17:44:46] and I always have that disabled [17:44:55] as well as the music playing when outside [17:45:17] there is a "Never Play MP3" option [17:45:46] have you even tried looking outside? :D [17:46:03] oh yes, I already found that option and turned it off [17:46:13] that music was very annoying lol [17:47:39] used to be Air from Bach, much better [17:47:50] in an earlier Orbiter Sound version [17:48:09] https://www.youtube.com/watch?v=rrVDATvUitA [17:48:53] you can also delete the MCC vessel in the scenario, that definitely gets rid of the MCC displays [17:50:02] ah nice [17:50:10] I have much scenario editing to do, haha [17:50:48] oh yeah, the Bach would have been much less annoying [17:51:20] unless you like getting a lunar ascent PAD for the next rev [17:51:39] oh! I had another question [17:51:39] I guess with everything you have in place now you can also easily do aborts or ascents [17:51:50] oh man [17:51:54] I hadn't thought about that [17:52:02] so much fun stuff to do :D [17:52:04] needs nothing fancy like a descent [17:52:07] abort stage button [17:52:13] which probably already works [17:52:14] right click to remove the cover [17:52:16] yeah [17:52:23] awesome [17:53:01] always fun to watch [17:53:18] the bang at staging is a bit loud I find, otherwise it works well [17:53:23] but yeah, question: on touchdown I have to hit the STOP button to switch off the main engine, but the RCS continues to fire like crazy and the post-landing checklist steps don't appear to make it stop. is this because I'm landing in P65 and am not in ATT HOLD? [17:53:31] aha! [17:53:36] I knew you were going to ask that [17:53:39] hah [17:53:50] the DAP does attitude hold normally [17:53:58] or at least something close to attitude hold in P65 [17:54:14] then you touch down and the ground contact is going to change your attitude a bit [17:54:20] DAP doesn't know you landed [17:54:22] right [17:54:28] so it's going to try to get back to the old attitude [17:54:37] makes sense [17:54:38] that's what the "ACA Out Of Detent" is [17:54:43] for P66 at least [17:54:51] what does the checklist say for P65... [17:55:03] ACA out of detent resets the attitude to hold [17:55:12] aha [17:55:15] without commanding a large attitude rate, so no large deflection [17:55:19] just a bit [17:55:24] doesn't really work well with keyboard [17:55:29] lol, right [17:55:57] later Luminary versions added the ability to just press PRO in P66 to do that attitude reset [17:56:12] oh that's nice [17:56:39] if the P65 checklist also calls for ACA out of detent... could I just go to POOH? [17:57:07] V37E 68E [17:57:16] oh P68 [17:57:16] landing confirmation program is the next step [17:57:27] checklist: [17:57:28] interesting, I didn't know about that one [17:57:32] after LM is stabilized: [17:57:37] S/C PGNS sw - ATT HOLD [17:57:50] ACA - out of detent momentarily (to deactive RCS thrusters, if required) [17:58:01] after first lunar stay go decision is made: [17:58:04] V37E 68E [17:58:14] so not really directly, I forgot [17:58:30] if you don't get the first STAY then you just abort as if you were still flying [17:58:38] right [17:58:41] P70/P71 aren't available after calling P68 [17:59:36] if the landing site elevation wasn't correct, then staying in P66 (or P65) on the surface for a while screws up the SV a bit [17:59:55] accelerometers still running [18:00:14] we could also modify your scenario to have a very accurate landing site vector [18:00:32] in NASSP it currently just isn't possible to downlink P22 data and use that for a better one [18:01:04] well, you can do P22 in the CSM, save the new RLS and then give that RLS to the LGC as well [18:01:16] annoying without mission control [18:01:17] eh, I don't want it to be any more accurate than the real mission was [18:01:30] I am pretty sure their RLS was more accurate than ours [18:01:40] they had other sources of SV errors [18:02:21] I can understand having it not too perfect [18:02:58] terrain is super flat, you probably might get double digit DHs [18:03:05] instead of 3000+ [18:03:27] yeah, more fun to make the LR have a big impact [18:03:51] Apollo 11 (and its LGC padload) are even quite conservative with that [18:04:02] later they let the LR data converge much more quickly [18:05:28] wouldn't want to fly to the Apollo 15 landing site with that happening slowly [18:06:50] haha yeah [18:06:53] definitely not [18:07:29] I saw the worst of what can happen there on my third-to-last landing attempt last night [18:07:44] when I tried to go off of the checklist by memory and keyed in V56E to accept radar updates instead of V57E [18:08:24] haha, nice [18:08:47] I hit the surface going very fast :D [18:09:45] I think I know how to handle the RLS with the MCC in the future. Launch with the padloaded one, then assume the CMP did perfect tracking and uplink the RLS with the correct radius before landing. [18:10:01] I'll implement that for Apollo 11 soon [18:15:54] ugh [18:16:01] I just want to go home and fly more landings [18:16:17] and ascents [18:16:22] haha yeah [18:16:26] try hitting that abort button [18:16:39] or abort stage [18:23:31] hmm [18:23:49] the other thing I should do is make a scenario file setting for whether to use the hardware AGC or the virtual AGC [18:23:58] so I don't have to keep recompiling to change it [18:24:31] sounds right [18:24:31] oh or maybe I should just make it try to autodetect the hardware AGC and fall back to virtualagc if it can't find it [18:25:06] that would be a lot easier to implement... [18:25:10] but also could lead me to thinking I have a hardware AGC when I actually don't, heh [18:25:31] yeah, I'll make it a scenario thing [18:25:41] oh [18:25:46] I think I found a minor bug in NASSP last night [18:26:09] NASSP and bugs? Madness! [18:26:50] https://github.com/thewonderidiot/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_sys/apolloguidance.cpp#L790 [18:27:07] should there be a break there? or does the imu want channel 12? [18:27:41] looking at it now I think it was just overly sleepy me thought it was a bug... [18:27:58] no bug [18:28:03] right [18:28:06] I will un-fix that [18:28:08] haha [18:28:10] ProcessIMUCDUErrorCount needs channel 12 as well [18:28:14] this is what I get for 3am coding [18:28:43] should probably say "fall into" in the comments there, or so [18:29:01] and IMU also needs it [18:29:11] yeah [18:29:23] probably breaks a bunch of things, but none too relevant to you right now [18:29:28] haha [18:30:01] I need to go through NASSP and un-make a bunch of changes I did early on before I really narrowed in on the right approach [18:31:54] Git GUI always helps me with that [18:33:21] I think once I back all of that out the changes should be fairly surgical, and entirely confined to apolloguidance.cpp [18:34:21] very nice [18:35:13] if there is nothing changed in LEMComputer then you probably also have a functional CMC now [18:35:21] yeah :D [18:35:51] that will be enabled by the scenario flag for hardware AGC -- right now I'm constructing the AGC bridge in LEMcomputer but with the flag there will be no need for that [18:35:57] entry guidance is also always a nice demo [18:36:11] yeah, I'll have to learn how to do that :D [18:36:36] works quite automatic, but I guess you will still need to know about the different phases [18:36:39] there is P61 to P67 [18:36:56] pretty sure we have a scenario just two minutes before reentry, not much to do there [18:37:03] not much left to do* [18:37:04] I've finally hit the crossover point and am going to be actually flying missions in NASSP! :D [18:37:09] it just took me five years to get here [18:37:27] did you even know about NASSP in 2014? :D [18:37:43] I was vaguely aware of it, haha [18:38:06] I probably considered it to be a mostly dead project, like virtualagc [18:38:31] slightly less dead, because virtualagc was very dead [18:38:34] yeah, things picked up with NASSP in about 2015 [18:38:34] but still :P [18:39:16] from 2013 to 2015 I helped with some Apollo 7 rendezvous things, but I mostly developed the RTCC MFD as an external project [18:40:00] ah right [18:42:07] you and your many MFDs :D [18:43:14] at this rate there is a LCC MFD coming soon [18:43:29] hahaha [18:43:54] how is your shuttle MFD doing, by the way? [18:44:21] haven't updated it in a while [18:44:33] nobody complained about things not working in a while either [18:44:44] but it's also difficult to use, so it might just not really be used [18:44:50] hehehe [18:45:06] I have the same launch window calculations in NASSP already [18:45:16] and we recently fixed a LVDC bug, making insertion more accurate [18:45:32] so I could wire it up and try to get a Skylab 1/2 scenario or ASTP or so going [18:45:37] oh nice [18:45:43] man we need to find a set of skylark modules [18:45:52] we sure do [18:46:45] there should exist at least 4 of them, which we can't say about any other version [18:46:53] hehehe [18:48:14] you are probably in the position to accelerate that search in just a few days [18:48:19] no, we can say that about a lot of versions [18:48:55] looking at the KSC rope module status memo -- "Luminary 210, Set 5", "Artemis 72, Set 4", "Comanche 45-2, Set 7 (???)" [18:49:03] yeah, absolutely [18:49:12] 7 of Comanche 45-2 of all things [18:49:19] I need to send another call for rope modules out to the apollonauts list [18:49:52] Comanche 45 was the first version to have the full rendezvous programs [18:50:04] so that might have helped make it desirable to have [18:50:07] five Sundance 306s as well [18:50:09] ah maybe, haha [18:50:17] still 7 sounds excessive :P [18:50:49] how many running AGCs were there even on the ground then [18:51:17] you don't need ropes for most of the simulators [19:28:35] that's a good question [19:29:07] http://www.ibiblio.org/apollo/Documents/what_where_are_computers.pdf [19:30:31] I want to know what happened with C19 [19:30:36] "peculiar history", haha [19:32:05] haha [19:32:40] oh, another question for when I'm giving talks -- do you pronounce NASSP as its letters, or as a word? [19:34:03] as the letters, I think [19:34:15] okay, that's what I thought, just wanted to make sure [19:34:16] but you better ask dseagrav about that [19:34:34] I'll ask him next time I see him :) [19:34:51] Nasa’s Apollo Space Simulation Project [19:35:14] or maybe rather: Nasa’s Apollo, Space Simulation Project [19:35:30] officially "Project Apollo - NASSP" [20:08:03] night! [08:16:30] .tell indy91 https://www.youtube.com/watch?v=Z5NdstM-W4s [17:06:56] morning! [17:08:49] hey Mike [17:08:54] what's up? [17:08:59] yeah, saw it a few hours ago [17:09:02] wrote you a comment [17:09:08] I saw :D [17:09:13] thanks! [17:09:35] one thing that confused me was that the descent speed in P65 and the tape meter didn't agree [17:09:42] oh really? [17:09:44] hm [17:09:45] they agree for Apollo 15 though, so that must be the bug [17:09:54] which Don had to fix [17:09:58] right [17:10:17] it shows 1 ft/s descent speed when it actually has 3 ft/s [17:11:20] first thought it was our code for displaying the tape meter, but I think it's all the LGC software [17:12:12] and you didn't switch on descent engine command override :D [17:12:34] haha, I don't have anything to override it with :P [17:12:48] unless that's all NASSP side [17:13:09] that's a switch [17:13:14] nothing to do with the AGC [17:13:14] I know it's a switch [17:13:17] but it's in the checklist [17:13:23] you didn't flip it after ignition [17:13:25] but I assume I then have to move something if I want to override the throttle? [17:13:31] once the switch is set [17:13:45] no, most people have a misconception about that switch [17:14:03] ah, I apparently read one of the misconceptions :D [17:14:10] it just keeps the engine running, if the DECA looses power intermittently [17:14:16] gotcha [17:14:26] that is definitely not what I read haha [17:14:29] I will hit that next time [17:14:38] I implemented it relay by relay, hahah [17:14:41] pretty sure about it [17:14:45] totally fair :D [17:14:54] after landing, you press engine stop [17:15:13] if you disable engine stop again and the descent engine is still armed then the engine might start again [17:15:21] due to the descent engine command override switch [17:15:26] oh fun [17:16:30] other than that, just the things I wrote in the comment [17:16:57] I could swear the checklist MFD says +7:25, throttle 57% -- is that just saying that that's the absolute latest for throttle down? [17:17:13] hmm [17:17:17] maybe a typo [17:17:31] or no [17:17:44] we didn't have the Apollo 11 LM Timeline Book when the checklist was written [17:17:53] ah [17:18:05] so it was first written with the Apollo 12 one [17:18:09] gotcha [17:18:11] makes sense [17:18:16] later missions had later throttle downs [17:18:22] so still a checklist error I guess [17:18:41] wasn't changed with the other things when the Apollo 11 book became available [17:19:09] timeline book has the throttle down next to the 6:30 time [17:19:15] without giving a specific number [17:19:31] any idea why I wouldn't have had an RR lock on this run, when I did on previous runs? [17:19:34] oh, I am dumb [17:19:40] ? [17:19:43] the checklist is actually based on previous NASSP behavior [17:19:47] hahahaha oh man [17:19:48] we used to get 7:25 throttle down [17:19:56] but with my DPS improvements it is now 6:45 [17:20:08] hehehe [17:20:30] not sure about the RR [17:20:47] would going to POO and then back to P63 have any effect there? [17:20:58] it seems like it waaaaaiiiit a minute [17:21:02] I deleted the CSM from my scenario [17:21:05] that's what did it [17:21:06] hahahaha [17:21:30] mystery solved :P [17:22:16] not quite sure why there is a master alarm at the start of your scenario [17:24:19] is it because of the RESTART? [17:24:26] yeah, possible [17:24:34] if not, the only other thing I noticed is a red ACS PRESS light [17:24:39] on the light panel at the top [17:24:54] also could be the RR light, I tend to get a master alarm when that light comes on [17:24:55] yeah, but that should only start a master alarm if it goes off and on again [17:25:04] maybe the alarm was there when you saved? [17:25:11] if not it's a saving/loading bug [17:25:16] I don't think so [17:25:16] oh [17:25:26] or maybe a startup issue with the FPGA [17:25:40] that could be [17:25:40] yeah, probably has to do with that [17:25:42] the restart [17:25:48] and at some point you are getting 4 red RCS TCA flags [17:25:53] at around the time of landing [17:26:19] those have been annoying for quite some time [17:26:26] haha [17:26:28] but other people seem to get them more often than me [17:26:30] what causes that? [17:27:02] in theory a firing command to the RCS (from any source) being present, and the RCS thrust chammber pressure not being high enough (so RCS not actually firing) [17:28:47] maybe just some weirdness going on at ground contact [17:30:03] oh, and you said something about a possible delay of RCS commands [17:30:07] what was that based on? [17:30:30] the LM not holding a steady attitude during the early parts of the descent? [17:52:05] nah, just based on there potentially being 1-2 frames of delay between me requesting channel 10 from the monitor, and actually getting that data back with the value of channel 10 [17:52:13] it's not instant because of the USB transit [17:53:12] right [17:53:48] attitude control of our LM is not optimal in the first half of the descent due to center of gravity issues [17:54:23] ideal case is RCS doesn't have to do anything and it is all DPS gimballing, but that is rarely the case [17:54:33] yeah [07:10:52] .tell indy91 I cleaned up all of my code; would you mind looking through it to see if I've done anything dumb, or missed anything obvious? https://github.com/thewonderidiot/NASSP/pull/1/files [12:09:10] . [17:04:03] morning! [17:18:02] hey Mike [17:18:33] found one bug in the LM that can cause random master alarms at scenario loading [17:18:51] I guess you can still merge updates fairly easily, as long as they aren't in the AGC part [17:19:01] and I made you a Zerlina scenario [17:22:02] and you code looks good. Quite simple [17:22:05] your* [17:37:00] thanks! [17:37:05] yeah I can merge stuff easily :D [17:37:25] the Zerlina scenario I had with all the padload fixes was in P63, 2 minutes before PDI [17:37:37] so I took an earlier one and did all the same adjustments [17:37:53] so it's in P00, 5 minutes before PDI, all other vessels deleted [17:38:08] oh man that's perfect [17:38:10] thanks a bunch! :D [17:38:21] man now I really need to get LPD working [17:38:30] the terrain at the landing site is very rough, but it lands at a good spot with the help of N69 values already loaded in the scenario [17:38:40] LPD is just input bits [17:38:45] as is the ROD switch [17:38:51] but maybe a HANDRUPT? [17:38:57] yeah, the HANDRUPT is the challenge there [17:39:02] ah [17:39:18] because the fake channels I'm using can't trigger the interrupt detection circuits [17:39:20] so not the registers for the ACA deflection [17:39:37] or would those also be difficult? [17:39:44] those are easy, if you're calculating counts [17:40:01] I can just write those in like the ICDU values [17:40:05] in any case, it will land in an ok spot [17:40:09] I think the HANDRUPT is the only hard part [17:40:19] there is one thing Auto P66 doesn't do that P65 does [17:40:27] it's descending at a specific rate [17:40:41] Auto P66 just starts with the descent rate it had when it switched over from P64 [17:40:47] right [17:40:48] P65 has a padloade descent rate [17:40:52] padloaded* [17:42:08] the Zerlina scenario also has the ignition algorithm padload from Apollo 15 (we didn't have 14 yet) [17:42:23] so it does the throttle down quite early, due to its normal mass [17:42:30] not as heavy as the J-mission LM [17:42:35] ah interesting [17:42:41] about 5:52 [17:42:47] oh wow that is early [17:42:49] confuses P63 a bit [17:42:51] haha [17:43:03] pitches up in late P63 [17:43:08] then down [17:43:11] and then into P64 [17:43:18] I've seen that happen a few times on my 11 landings [17:43:19] it's noticable, but not really extreme [17:43:27] in some instances it will pitch quite a bit and go back to full throttle for a while [17:43:40] I think it happens when I incorporate the radar readings too late and it realizes it's way too low [17:43:52] yeah, probably [17:44:02] maybe with Zerlina it also has that effect with the weird terrain [17:44:09] yeah for sure [17:44:10] north of Tycho crater [17:44:50] the earlier pre PDI scenario even had the LGC clock error still :D [17:45:01] lol [17:45:05] whoops :P [17:45:21] I remember having to do a -6000 ft in N69 [17:45:48] part of that is clock error, part the LR issue that is now fixed [17:45:50] yeah, I remember the first time you landed you weren't even close to where you were shooting for [17:46:13] both downrange and crossrange, yeah [17:46:34] it's pretty crazy how far we've come, haha [17:47:50] speaking of coming far, right now I am having fun with not launching Saturns [17:48:04] by inhibiting the launch, haha [17:48:10] hehehe [17:48:12] EDS power off does it [17:48:25] that seems like a good safety feature to have [17:48:38] yeah [17:48:50] right now it still doesn't inhibit the launch completely [17:49:01] so in some cases you can switch EDS power on again and it will launch :D [17:49:26] like immediately [17:49:31] hahahaha oh man [17:49:37] that is not at all a good safety feature :D [17:49:44] yeah, needs work [17:49:52] a proper terminal countdown sequencer for example [17:49:58] and I also moved the GRR trigger for LVDC to the mobile launcher "computer" now [17:50:05] speaking of a ground computers [17:50:08] https://forum.nasaspaceflight.com/index.php?topic=46255.0 [17:50:15] have you read about this project? [17:50:24] I'm pretty sure I figured out what they digitized [17:50:31] I think you sent me a link to this when they first posted about it [17:50:33] oh yeah? [17:50:48] it's a complete list of discrete inputs and outputs of the ground computer [17:50:56] oh that's pretty darn cool [17:51:13] indeed [17:52:13] with my EDS test I am currently at the point where I would need to send some signals to the IU, but also some to the S-IC. So the common interface is probably going to be these input/output discrets [17:52:35] would this manual I have have any pertinent information then? http://www.ibiblio.org/apollo/Documents/SLCC_Programmers_Reference_Manual.pdf [17:53:04] it lists lots of card formats for that system [17:53:55] I think that is basically a guide on how to write automatic checkout routines for the computer, right? [17:54:17] the LAUNCH VEHICLE INPUT/OUTPUT chapter is probably useful for me [17:54:36] but other than that I'd rather be interested in finding the automatic checkout routines that were used [20:17:34] night! [20:23:33] for the longest time I thought nASSP was dead because there hasn't been a forum post for nearly a year, and then I find out that nope, it's just moved [21:46:02] hahaha yeah [21:46:16] the old forums were giving us big problems so we moved to an Orbiter subforum [22:23:47] where is the current source now? [22:23:53] the dseagrav github appears to just be releases [22:51:01] Schroeder: it's on the dseagrav github; you just have to switch to the Orbiter2016 branch [22:51:06] the master branch is only for releases [22:51:37] ah [22:54:06] thanks [22:55:27] sure thing :D [15:40:34] Hey [15:45:37] hey Alex [15:46:22] what’s up? [15:47:35] improving ML code mainly [15:47:47] nice [15:48:52] never go to Florida in July... way to hot :D [15:48:56] haha [15:49:14] I have seen Florida in July with my eyes, but I wasn't there, lol [15:49:33] vacation on https://en.wikipedia.org/wiki/Jekyll_Island [15:49:34] still too hot [15:51:18] did you see the ascent abort test? [15:53:44] I didn’t get there until the following evening, but I saw the footage. Pretty cool [15:54:07] ah, right [15:54:47] Looks quite similar to what I have been practicing lately in NASSP [15:54:53] haha, yeah [15:55:12] NASSP has more parachutes [15:55:46] one thing I did so far was moving the GRR signal to the launch pad code [15:56:04] seems to delay GRR by one timestep more, but doesn'T seem so bad [15:56:24] part of the never ending quest of making things less mission time dependant [15:56:37] previously GRR just happened at -17 seconds mission time [15:57:17] right [15:58:33] at T-20 minutes the LVDC would get a prepare to launch signal and that's when it would sync its clock the last time with ground systems [15:59:02] that is still missing for us, then there should be no more Sat->GetMissionTime() involved [16:01:35] or worse, calling an Orbiter API function to get the time [16:01:52] at least in LVDC code I consider that bad [16:06:59] I guess that LVDC is a bit less polluted now haha [16:07:21] a bit, yes [16:07:25] still a bit to go [16:08:51] and I'm still finding more EDS things to go [16:09:15] like the "All S-I Engines Running" signal, that is from the EDS to ground and one part of the decision to commit to launch [16:09:47] All Engines Running, No Cutoff Signal, Time for Commit. That is what let's the Saturn launch [16:24:29] I wonder when we’ll see the 1st post “Saturn 5 doesn’t launch” and of course the reply “flip up the EDS switch” :D [16:27:09] haha, yeah [16:27:19] but why would you forget that switch in the checklist! [16:35:28] yeah true [16:37:50] and what I still need to improve is that the Saturn launches anyway, after flipping EDS power on again [16:38:03] needs some ML timeline restructuring [16:40:15] I had tested it and it didn’t launch again on the latest update [16:42:34] I think it still depends on when you switch it off and on [16:42:45] and it behaves a bit different for Apollo 7 [16:43:11] I at least want it to get to the point where liftoff is permanently inhibited [16:43:16] in all cases [16:43:37] further down the road we can implement countdown holds etc., but that is probably not possible yet [16:49:49] Just watching Mikes landing video, pretty cool [16:50:01] yeah [16:50:08] I made him a Zerlina one as well [16:50:21] nice [16:50:34] anyway I gotta go, cya [16:50:46] cya! [17:41:52] morning! [17:55:38] hey [17:56:31] hey [17:56:32] what's up? [17:57:35] nothing new really [17:57:36] you? [18:15:07] getting ready to book flights for the trips to Florida and Boston [18:19:42] what's in Florida? [18:19:47] Eldon :) [18:20:34] ah, so he finally listened to his voice mail? :D [18:21:12] haha, maybe, but he at least picked up his phone [18:21:50] so he will get a private demo then [18:22:26] yep [18:23:57] nice [18:24:33] better make sure the AGC is working properly again by then [18:26:30] feel free to request any kind of core file or NASSP scenario, so far they have been quite quick and easy to generate [18:30:27] thanks! :D [18:32:10] and in the next few days I'll have the least buggy version of NASSP up that I can come up with [18:32:22] hahahaha [18:32:24] well, just that one LM master alarm bug and I'll try not to create too many new ones [18:33:00] lol [18:33:14] the Zerlina scenario is ready, but still haven't done the changes for the more realistic ignition time [18:33:54] just the padload for the ignition algorithm and then I would just modify the event timer timet to the new TIG [18:34:03] time* [18:34:28] awesome [18:34:40] and I guess I should also make a good Apollo 15 scenario [18:34:48] and 17, also nice terrain [18:34:48] hopefully I'll have the hand controller working in a couple of days [18:34:53] ah [18:35:10] we have those scenarios, just would have them in P00, 4-5 minutes before PDI and with other vessels deleted [18:35:26] right :D [18:37:53] I haven't actually done a 17 landing yet since that LR fix in May last year [18:38:25] should be quite possible to study the maps and do the landing in the right spot [18:40:55] oh nice [18:42:09] in your video you haven't even installed the high res textures/terrain [18:42:17] but they are quite large files [18:42:52] 14.4 GB [18:42:55] for the Moon [18:43:07] Earth is even much more [18:47:42] oh weird, I have the files [18:47:56] might still be something weird with my beta install then [18:49:15] oh, maybe you have it installed then [18:49:25] maybe it doesn't really come across in the video [18:49:50] or maybe some different micro textures setting [18:50:04] I'm not sure my laptop will be able to handle it anyways haha [18:51:15] yeah [18:53:09] probably just looks different in the video [18:53:26] you are on more up-to-date versions of Orbiter and DX9 Client than I am :D [18:53:53] have you seen the shadow of the LM during a landing? [18:54:04] uhhhh [18:54:07] I don't think so [18:54:33] I am not seeing it in the video. And there was a bug related to that in the DX9 Client. But also could be a setting [18:55:27] bug was in a much older version, so it's probably not that [18:55:46] being able to see the shadow of the LM is a pretty important thing [18:56:48] in the Orbiter launchpad, Visual Effects/General effects has some settings related to that. [18:57:02] So maybe check that the next time, maybe something is missing there [19:08:31] hmm, okay, I'll do that [19:08:46] I'm going to be going through the install process on my laptop here pretty soon [19:14:14] I wish you a good frame rate :D [19:18:34] man I hope so [19:18:45] I have two laptops here with which to accomplish that -- my personal laptop and my work laptop [19:18:52] hopefully I can get a decent framerate on one of the two [19:19:08] if not I don't know what I'm gonna do, heh [19:19:25] defect to Eagle Lander 3D? :D [19:19:59] on a laptop the graphics will also be a limiting factor [19:20:18] on a normal PC it usually is the CPU, with the emulators and our bad 2D panels [19:20:38] but the LM is definitely much better in terms of performance [19:20:47] smaller main panel with fewer interactive elements [19:21:19] much better than the CSM* [19:21:22] lol [19:24:44] yeah [19:24:51] I think my work laptop can proooobably handle it [19:25:01] it would just be really nice if my personal laptop could too [19:44:23] okay, all rooms and flights booked [19:46:11] busy schedule off work, haha [19:46:48] yeah no kidding [19:46:59] it will be nice to be able to use vacation time for vacation again, haha [19:48:35] alright windows time [19:48:51] I don't think I've booted into windows on this laptop since the day I got it [19:50:36] hm [19:50:40] logged in and the screen is black [19:50:42] not a good start [19:51:16] it's showing you what it thinks about you, not using Windows for so long [19:51:25] hehehe [19:52:23] there we go, logging out and back in fixed it [19:52:36] I wouldn't mind if Orbiter was Linux compatible, but I have the feeling performance wouldn't be any better [19:54:40] yeah I don't think performance would be different, but it would make things a lot easier, heh [19:56:02] okay first up, orbiter beta [20:00:23] while windows hogs all of my CPU doing updates [20:00:31] obviously [20:01:07] ah, I just made stopping launches with the Saturn V much better [20:01:16] lol [20:01:25] had to modify the sequence in the ML, which was a bit scary [20:02:05] but now when it goes to the next phase it does a check if the conditions are met [20:02:34] if not, then it holds [20:02:40] right now forever [20:03:24] recycling and launching later is faaaar away [20:03:25] nice [20:03:28] hahaha [20:03:44] okay this isn't helpful. I just need to sit and wait [20:03:56] I wonder how much I woulf have to do to make the LVDC compatible with recycling [20:04:06] after GRR [20:04:10] windows has cancelled two downloads of Orbiter by futzing around with my wireless drivers and disconnecting my internet [20:04:33] seems like it would be a lot [20:04:54] maybe [20:05:11] depends how many presettings it overwrites [20:05:26] but mainly it has to go back to timebase -1 again [20:05:30] our pre GRR state [20:06:11] if the LVDC idles too long in TB0 then it would put itself in a one instruction loop [20:09:55] I really don't think going back from TB0 would be a big issue [20:10:31] setting a bunch of flags [20:11:44] elapsed time [20:22:20] third restart [20:22:26] wonder how many more times this will happen [20:25:52] anything Windows wants to install obviously takes priority [20:26:53] oh, windows is up to date! [20:36:10] okay, so far so good [20:38:44] indy91, do you use the TextureDir thing for your orbiter beta installation? [20:38:51] no [20:39:01] you just copy the textures over? [20:39:13] I copy Orbiter Beta over, haha [20:39:17] can't recommend that method [20:39:18] haha gotcha [20:39:24] yeah, I haven't been able to make it work [20:39:35] there was something about it [20:39:40] some weird thing [20:41:26] okay, framerate seems good enough without NASSP installed [20:41:36] that's a good sign [20:41:48] yeah [20:42:10] now, visual studio [20:43:06] community 2017 [20:43:14] just let me download the old one, microsoft [20:44:15] but 2019 is so much better! Among many other features it can not build NASSP [20:44:53] I even have Visual Studio 2010 installed still [20:45:00] hahahaha [20:46:00] our telemetry client doesn't build with anything else [20:46:11] but I think I first had it installed when NASSP was still using 2010 [20:47:31] yeah that sounds right [20:47:47] I used to use 2010 a whole bunch [20:49:06] good version for the time [20:54:08] oop [20:54:11] reboot time again [20:58:43] Windows likes rebooting [21:02:42] one source I have for the times when the countdown is stopped automatically is the Skylab Saturn IB Flight Manual [21:02:51] and the Saturn IB on LC-39 is such a weird mixture [21:03:05] it must still use electronics in the ML for the Saturn V [21:03:26] there is a hold point at T-30s, that's when the Saturn V had service arm 1 disconnected [21:03:38] the Saturn IB on the milkstool has nothing at that point [21:04:00] same at T-16.2s, the Saturn V had its next service arm disconnected [21:04:13] nothing for the Saturn IB, but a countdown hold point at that same time [21:04:45] the last point is just before ignition sequence, that finally is a time in the countdown from the Saturn IB [21:06:40] hmmm [21:06:54] I guess that makes sense [21:07:00] whoever had the idea to put a Saturn IB on LC-39B was a bit crazy, but probably saved a lot of money [21:07:04] hahaha [21:07:58] or rather, 4 Saturn IBs [21:11:00] oh [21:11:00] 5 [21:11:13] 5? [21:11:13] the Skylab Rescue Saturn IB was on LC-39B twice [21:11:18] without launching [21:11:19] ahhh [21:11:24] never knew that [21:12:02] AS-208 (Skylab 4) was rescue vehicle for AS-207 (Skylab 3) [21:12:16] AS-209 (Skylab Rescue) for AS-208 [21:12:23] so AS-209 was only on LC-39B once [21:13:07] not sure about ASTP [21:19:51] ooookay, NASSP cloned and all of the dependencies are installed [21:20:07] let's see if I can build it [21:21:38] good luck, sent me a .tell if you have any issues [21:21:46] will do, thanks! [21:21:47] night! [21:21:49] night! [14:35:47] Hey [14:36:45] hey Alex [14:37:03] pushed my updates of the last few days [14:38:18] The times at which a hold can be initiated should now be quite realistic [14:38:19] yeah I saw. I don’t have access to my pc to test the changes but I will tomorrow probably [14:38:26] sure [14:38:42] and in no case will it be able to launch after a hold [14:38:51] Like a countdown hold? [14:38:55] yeah [14:38:58] and it's only checked at discrete times [14:39:08] so switching EDS power off and on again will be safe at most times [14:39:15] How is that initiated? [14:39:27] mainly EDS power on/off [14:39:36] right [14:39:40] there will be other things that can cause a hold in the future [14:39:48] it is checked at T-187s (automatic sequence starts) [14:40:01] then at T-30s, just before the first service arm is retracted [14:40:07] that's where Apollo 17 had its hold [14:40:22] then T-16.2s, before the next service arm is retracted [14:40:54] and after T-8.9s, ignition sequence start, any cutoff signal immediately stops the countdown [14:41:12] had to mess with the ML state logic which was a bit scary, but I'm quite happy with the result [14:42:42] Hey guys. What's up? [14:43:04] making scenarios for Mike to demo with his FPGA and/or the real AGC [14:43:21] and fun prelaunch stuff, like not launching :D [14:43:32] hey Thymo [14:44:06] Haha sweet. [14:44:43] I've been meaning to get back to AndroidAGC but Android Studio needs me to update a million things first. [14:44:58] ouch [14:45:29] I have an android phone since the beginning of this year, I really should try to get your AndroidAGC working [14:45:36] how do I get it? [14:46:00] I'm not sure if I released the apk to github. Hang on a sec. [14:46:00] indy91, I saw the S1B got the same treatment now (countdown holds) [14:46:25] No, I did not yet do that. [14:46:36] The repo is here though, should be public: https://github.com/Thymo-/AndroidAGC [14:46:39] didn't Mike test it? [14:46:50] probably build it himself then [14:46:52] Yeah, I did a custom build. [14:47:09] There've been some changes so I'll do another build once my IDE is working. [14:47:21] AlexB_88, yeah, although I had to update the Apollo 7 T-60s scenario to make it work [14:47:33] should only be an issue with old Apollo 7 scenarios though, not Saturn V [14:47:44] I still haven't gotten around to fixing that darned timing. It's always running to slow or too fast. [14:48:10] sure, I think I'll wait with trying to getting it running then [14:49:14] so, as Orbiter doesn't have a new release out with the updates we need it wasn't really worth trying to get NASSP 8 done by the Apollo 11 anniversary [14:49:27] but, I think that's a good opportunity to finally go from Alpha to Beta [14:49:35] Woo [14:50:26] Agreed [14:50:55] What's broken in Orbiter this time? [14:51:19] oh, I just meant that Orbiter 2016 release version isn't good enough for us [14:51:26] the moments of inertia issue mainly [14:51:47] Oh, that's still only in the beta? I guess you're right. [14:51:50] and there hasn't been a Orbiter 2016P1 or so [14:51:56] yeah [14:52:05] Maybe we can persuade Martin? [14:52:25] I think it would of been a too short beta period if we had aimed for the anniversary anyway [14:52:52] yeah [14:53:01] last beta period was 10 years :D [14:53:03] Not that there are many bugs left to squash [14:53:22] I still want to try and improve performance, but every time I try I find a new obstacle [14:53:32] I doubt we’ll beat that record :D [14:53:40] yeah [14:54:21] Have we looked into new panel code yet or is that saved for NASSP 9? [14:55:33] one thing I want to look into is if we can create 2D meshes (instead of bitmaps) without having to change everything [14:55:51] other than that we probably want to go directly to a full 3D panel, if we are starting such a project [14:55:57] and that's certainly NASSP 9 [14:59:54] Definitely [15:01:06] anything without bitmaps will improve performance a lot, as it's shifting the processing from CPU to GPU [15:01:32] When I find some time (wish I had more) I wanna take a look at making a new ground control program. I don't think that old .NET thing is really gonna cut it anymore, if we even manage to compile it. [15:01:47] you mean the telemetry client? [15:01:52] Yeah [15:02:05] we have a whole LM PCM just waiting to send its data :) [15:02:18] I made it quite complete [15:02:25] just no way to do anything with it yet [15:02:26] I like that [15:02:39] and the CSM one is buggy with high bitrate [15:02:55] randomly doesn't update stuff, haven't really been able to figure out why [15:03:07] but then I also don't understand half of the telemetry client code, so... [15:03:13] I'm pretty sure there is some document that described the mission control interfaces. Not sure which one it was though. [15:03:31] I looked at it. It gave me a headache. I'm not touching it [15:03:40] http://klabs.org/history/history_docs/jsc_t/mcc_operational_configuration_as15.pdf [15:04:42] that has each button and light for discrete states of all MCC consoles [15:04:56] nothing on the TV screen formats, which is unfortunate [15:05:35] Oh cool [15:06:40] if we had a way to process the telemetry then we could already have quite functional MCC consoles [15:07:46] and with all my recent additionals in the IU and elsewhere in the Saturn even the BOOSTER console would have stuff to display [15:11:41] I guess all the stuff to eventually talk to an “mcc app” [15:12:19] and LCC, which is mainly what I have been thinking about in the last few weeks :D [15:13:29] and I really like the new setup I have for GSE connections [15:13:50] it's linked to specific umbilicals and simply returns false if those aren't connected [15:14:01] very light-weight implementation I think, at least post launch [15:14:39] eventually I'd like to also do that for the CSM [15:14:49] has some special GSE code in satsystems [15:17:13] back in a while [17:07:33] morning! [17:08:04] I almost have landings working on my laptop, but not quite [17:08:30] it's fine until throttle down, and then I start getting occasional large transients in the radar readings that make the LM pitch around like crazy [17:09:09] and that happens for far too long, and by the time it decides to switch to P64 the vertical speed is too high to recover from [17:10:43] I think it might be occasional cases where NASSP starts to service one radar reading late in the radar cycle, but doesn't get the data in until the next cycle, so the reading is interpreted incorrectly [17:11:34] hey [17:11:49] hey [17:11:52] hmm [17:12:16] I think part of the problem might be NASSP's inability to control bit 4 of channel 13 -- normally it resets that bit after servicing [17:12:40] right [17:12:44] but since that's only reset by the radarupt itself in the hardware, where I don't have control over it, NASSP is going to keep taking readings through the entire radar cycle [17:13:43] so, if NASSP detects a request for data it should stop updating the internal values for the radar [17:13:51] so my first attempt at a fix tonight is going to be to specially handle that bit, and only allow NASSP to read it as a 1 once every time after the bit changes from 0 to 1 [17:14:35] to limit it to one reading per cycle [17:15:17] the problem is that the LR is writing new data to the register while the LGC is still processing? [17:17:32] what has that to do with throttle down? [17:17:52] or is NASSP too slow [17:17:59] due to worse framerate on your laptop? [17:21:47] I don't think it necessarily has anything to do with the throttle down, unless Luminary changes the pattern of readings it takes at any point [17:22:29] I think it's either too slow, or the problem exists with my desktop too and it's just that the timing is different [17:22:56] do you have the RR off? [17:22:59] um [17:23:21] not unless it was already off in that scenario [17:23:22] one thing to note there, to avoid some hangups I had to add some code to the LR and RR in their unpowered state [17:23:24] which I think it wasn't :P [17:23:52] after landing you normally pull the LR breaker [17:24:01] should it be off? is there an RR breaker I should pull? [17:24:15] and previously the computer was freaking out, because its requests to the LR weren't answered [17:24:23] that bit not being reset etc. [17:24:30] 1210 alarms I think, blocked the DSKY [17:24:55] right next to the LR breaker [17:24:58] hmm, I think that problem doesn't translate to the real AGC [17:25:11] indeed [17:25:21] since the AGC drives the radar cycle, that bit will always be reset and a radarupt will always happen, and it will just take whatever is in RNRAD as the response [17:27:02] https://github.com/thewonderidiot/NASSP/blob/agc_bridge/Orbitersdk/samples/ProjectApollo/src_lm/lemsystems.cpp#L2288 [17:27:18] same code is in the RR, for requests to the RR [17:27:32] in each case only if the radar bits are for that radar [17:27:55] not sure if this has to do with your issue, but it has to be taken into account [17:27:59] it might mess with things [17:28:14] RR off might be worse actually [17:28:17] it would only mess with things if the LR wasn't powered though right? i.e. if I don't have the breaker in? [17:28:25] RR without lock-on is probably the best [17:28:37] yes, but if the RR is unpowered in your scenario [17:29:57] right [17:30:04] I think RR without lock is what I have right now [17:30:12] ok [17:30:15] since in my scenario I've deleted the CSM but not changed any breakers or switches [17:30:18] I doubt the LGC will try to talk to it then [17:30:33] oh I wanted to ask [17:30:45] high scale / low scale [17:30:54] is that entirely astronaut controlled via a switch? [17:31:01] or can the LGC change scale? [17:31:18] if it's the latter I could see some timing problems there [17:31:24] ooooh [17:31:34] that's in the LR [17:31:40] and it sends a bit to the LGC [17:31:46] to interpret the data it is getting right [17:32:04] not to do with any switch [17:32:14] independent from the LR position [17:32:25] just how it processes LR range data [17:32:30] hmm [17:32:42] okay [17:32:58] so, if it sends a reading, and then changes scale [17:33:01] so that could indeed be a possible issue [17:33:16] okay cool [17:33:32] btw [17:33:55] I couldn't come up a really believable explanation about how the timing was affecting this, but if it's a scale/data mismatch that is very easy to explain [17:33:57] I'll put a bunch of scenarios there [17:34:04] oh perfect, thanks a bunch! :D [17:34:15] I wonder how it works normally [17:34:26] the software probably senses the input bit very quickly [17:34:34] checks it before processing the current data [17:34:54] yeah [17:35:03] no huge lag from different packets moving across USB [17:35:14] ah [17:35:22] so if the range scaling changes [17:35:30] it is sent via SetInputChannel [17:35:37] right [17:35:45] which, in the Virtual AGC changes the bit instantly [17:35:46] I think [17:35:50] and then further down [17:36:06] hmm, no [17:36:16] it just checks the local variable [17:36:17] val33[LRRangeLowScale] == 0 [17:36:21] hmmm, it doesn't look like the scale changes very frequently [17:36:24] which is what got changed just before [17:36:43] well, in the ideal case it changes exactly once [17:36:54] unless you like lunar descents that is ascending again [17:37:29] scaling change is at 2500 feet LR range [17:37:33] that is really, really late [17:37:47] if you get issues at around throttle down then it's not the scaling change [17:37:52] right [17:37:53] that is much higher [17:38:40] so, these lines [17:38:47] https://github.com/thewonderidiot/NASSP/blob/agc_bridge/Orbitersdk/samples/ProjectApollo/src_lm/lemsystems.cpp#L2499 [17:39:12] there's a comment that says range scale only affects altitude, not velocity [17:39:25] yes [17:39:30] but is it going to potentially toggle that bit during a velocity reading anyways? [17:39:54] like if the velocity is in the right range, could it change the bit? which wouldn't matter normally but if there's a timing thing then it might [17:39:59] well, it's checking that during any LR timestep [17:40:35] I doubt it matters during velocity processing [17:41:12] that should be all software [17:41:27] if it affects velocity then much worse things should be happening [17:41:45] I'm surprised you have the [17:41:46] lem->agc.SetInputChannelBit(013, RadarActivity, 0); [17:41:46] lem->agc.GenerateRadarupt(); [17:41:50] stuff in there still [17:41:54] does that not break anything? [17:42:00] no [17:42:16] SetInputChannelBit(013 is cheaty anyway from us, haha [17:42:19] I don't pass through the channel 13 write [17:42:23] right [17:42:31] and the radarupt thing won't have any effect [17:42:56] then it might simply be general timing [17:43:46] yeah. which I still don't have a great explanation for then, heh [17:44:01] we'll see what happens with the once-per-cycle tweak [17:44:17] is there a good way to see what framerate I'm actually getting? [17:45:41] yeah, there is a performance meter [17:46:01] which you have to enable under Modules [17:46:11] where you also set the checkboxes for MFDs etc. [17:46:17] called "Framerate" [17:46:22] ah perfect [17:46:33] and in the sim it's under custom functions [17:46:40] ever seen the scenario editor? [17:46:59] if not, I think it's Ctrl + F4 [17:47:12] no, I haven't [17:47:13] and that opens the menu where the performance meter will be [17:47:29] you'll find it [17:47:40] sweet, thanks [17:47:46] do you have VSync on? [17:47:50] no [17:47:53] should I? [17:48:06] you don't have to, I think [17:48:18] pretty sure Alex usually has it off [17:48:35] and to evaluate the framerate it might be better to have it off anyway [17:48:43] I prefer it on, smoother scrolling etc. [17:49:04] oh cool, okay [17:52:10] happy 53th anniversary to AS-203 [17:52:25] \o/ [17:52:29] I'm checking if I can set up a scenario [17:53:47] I might have broken non-CSM scenarios at some point [17:55:23] but apollo 5 is the best scenario! [17:55:47] well that's not a Saturn class anymore [17:56:12] that's basically a LM with a Saturn IB build around it now [17:56:33] while AS-203 will be a Saturn, with as much of the CSM disabled as possible [17:57:12] indeed a CTD, but I am sure I can get it working [18:00:04] ah, got it [18:00:12] just something I did wrong in the scenario [18:09:16] the question is if I can get our S-IVB-200 to do an engine restart, haha [18:14:59] hehehe [19:09:36] AS-203 did no mixture ratio shift. LVDC doesn't like having no mixture ratio shift. [19:11:28] but with the right presettings everything is possible [19:12:57] hehehe [19:13:08] just need to find those [19:13:51] so far I had pitching up wildly, then dividing by 0, then pitching down wildly [19:14:13] sounds like there's only one option left, haha [19:14:19] not pitching wildly, and not dividing by 0 :P [19:15:02] good idea, I'm trying that now [19:15:24] making it think it has already done MRS mainly [19:19:33] still not [19:19:37] what more do you want [19:31:59] also possible that I need to modify the pitch program [19:32:05] without payload AS-203 is super light [19:34:29] oh it recovered, I think it works now [19:40:42] yeah, works now, in principle [19:40:51] 3Gs at insertion, that's a bit unusual for a S-IVB :D [19:44:44] hahaha nice! [20:31:01] night! [21:31:44] Finally managed to get my android project synced. [21:31:54] Or taken the time rather. It just needs forever to resolve dependencies. [21:45:19] nice! [07:00:21] thewonderidiot, if you are still here, how is the LR behaving? [07:01:31] hey [07:01:32] poorly [07:01:47] and the good news is, it's behaving poorly on my desktop now too, and I can't land there anymore [07:01:48] so [07:01:58] step backwards, but at least it's consistent [07:02:36] haha [07:02:51] did you change anything? [07:02:59] too much, apparently [07:03:05] I'm not sure what broke it [07:03:35] what did you work on after the video, hand controller? [07:03:46] no, trying to get things working on my laptop [07:04:05] for reasons I don't yet understand, the build that gives me landings on my desktop causes the AGC to constantly restart on my laptop [07:04:15] I put it some workarounds to fix that [07:04:24] and it doesn't crash anymore, but that broke the LR on both places [07:04:29] I really need to root cause the crashing [07:04:34] hmm, ok [07:05:07] and what fixed the restarts? [07:05:11] I'm just finishing the FPGA changes that only let NASSP do a single radar reading per cycle [07:05:41] forcing peripheral instructions to only be able to start when the AGC is halted and between two instructions, and adding some additional halt/resumes [07:05:46] which certainly impacted timing [07:07:48] okay, FPGA building [07:08:09] I'm still wondering if something somewhere in NASSP is messing it up [07:08:14] if this doesn't work then I probably need to just abandon all of these changes, and break out the oscilloscope/logic analyzer and spend some hours studying waveforms tomorrow [07:08:20] nah, it can't be [07:08:23] but it might just be timing [07:08:40] unless certain channel values or PIPA/CDU readings would cause crashes [07:09:01] how is the frame rate on your laptop? [07:09:15] don't know yet [07:09:20] I've only tried on the desktop tonight [07:09:33] ok [07:09:38] and I'm in linux for the FPGA build so I can't try it [07:10:44] if this doesn't fix it then I will truly have no idea what's happening, haha [07:11:03] NASSP side can cause many things, but restarts are rarely it [07:11:08] yep [07:11:20] it's definitely something wrong in the monitor FPGA [07:11:26] injecting things onto the write bus when it shouldn't be [07:11:48] almost certainly during peripheral instructions... probably thinking that the AGC has started a peripheral instruction when it actually hasn't [07:11:49] unless you run out of power, then the AGC timestep isn't called anymore :D [07:12:13] heh [07:12:22] I don't think that's happening :P [07:12:29] yeah [07:12:59] but why was it ever different on your laptop [07:13:21] framerate affecting timing is the only thing I can think of [07:14:25] it might have just run fast enough to satisfy the AGC [07:14:26] okay, FPGA programmed, now I just need to point NASSP at my modified channel 13... [07:14:29] yeah [07:16:21] okay, new NASSP build is ready [07:16:46] what else is in channel 13? [07:18:45] hmm [07:19:05] switching to desktop, brb [07:21:01] throttle up [07:21:37] lots of mainly internal stuff is in channel 13 [07:21:40] hmmm [07:21:42] and the radar bits [07:21:45] I could also be losing time in the AGC [07:21:50] somehow? [07:22:21] guess we'll have to wait for the radar to see [07:22:37] but yeah, if I'm spending too long with the AGC halted I could potentially be losing timer counts occasionally [07:26:09] okay, coming up on the moment of truth [07:26:23] 30,000ft [07:26:24] aaaaand [07:26:40] uh [07:26:42] way worse [07:26:57] what's happening? [07:27:02] flashing vel, and my altitude disagreement is -19000 [07:27:05] and I just took a 1202 [07:27:14] awesome [07:28:08] and another [07:28:14] and now my N63 display is glitched [07:29:07] back to the drawing board then [07:29:30] yeah so [07:29:35] back all of this out [07:29:40] and figure out the cause of the restarts [07:30:22] amazingly I'm still alive [07:30:31] in P64 now [07:30:42] in doubt press abort stage :D [07:30:49] I'm definitely too high [07:31:00] did you allow the LR updates? [07:31:06] of course [07:31:10] more fun that way :P [07:31:33] plus +19000ft is more survivable than -3700ft [07:31:52] wow [07:31:54] in P65 now [07:32:13] I'm going to run out of fuel before I hit the surface though [07:32:20] yeah, probably [07:32:25] that's what abort stage is for :D [07:32:50] another 1202 [07:33:10] 3% fuel remaining [07:33:16] might as well let it finish before I abandon it [07:34:26] so it's in P65 but rather high up? [07:34:45] yep [07:34:54] whoa [07:34:58] close to surface abort is fun [07:35:14] another 1202 [07:35:36] I suggest opening the LR breaker [07:35:52] oh does the abort program use that? [07:36:19] I doubt it, but something must be causing the 1202 [07:36:23] true [07:36:33] computer load seems fine now [07:37:14] so where is P71 trying to put me? [07:37:46] depends on the time of the abort [07:37:51] how many minutes after PDI [07:38:03] this was after I should have landed :P [07:38:21] since I ended up just sort of hovering in P65 until my fuel ran out [07:39:01] right [07:39:36] N63 says I'm up to 43000ft and my velocity is 3000fps [07:39:55] so the insertion altitude is always 60k feet [07:40:15] and a late abort should end in the lowest apolune altitude [07:40:16] ah, cool [07:40:17] 30NM [07:40:25] but your SV will be a bit messed up [07:40:34] probably will make an ok orbit still [07:42:08] wow [07:42:19] according to the orbiter MFD, my orbit is basically circular [07:42:42] ApR 1.803M, PeR 1.755M [07:43:15] impressive [07:43:50] that's not that circular, haha [07:44:05] there should be a button to make that relative to the lunar surface [07:44:09] DST? [07:44:52] oh [07:44:56] yeah I guess you're right [07:44:57] heh [07:45:12] PeA 17.17k, ApA 64.89k [07:45:56] so doing some quick math your altitude is 66k feet instead of 69k feet [07:46:04] above the Apollo 11 landing site that is [07:46:18] that's what is usually used for altitude in lunar orbit [07:46:25] instead of 60k* [07:47:14] cool [07:47:18] well that was fun :P [07:47:26] definiteyl resuable [07:47:29] rescuable* [07:47:35] \o/ [07:48:07] perilune and apolune are both a bit messed up due to the SV I guess [07:48:13] perilune too high, apolune too low [07:48:29] that's better than the alternative, right? haha [07:48:35] indeed [07:48:50] the next step would be determining if the LM can rescue itself [07:48:59] alright, tomorrow I will need to break out the oscilloscope and study waveforms as NASSP writes in data [07:49:06] see if I can catch it being bad [07:49:25] for now it's bed time [07:49:33] good night! [07:49:35] night! [17:08:29] hey [17:13:19] hey [17:17:00] yesterday was the anniversary of AS-203, so I decided to give that scenario an update [17:17:30] nice [17:17:55] needed a bunch of LVDC updates especially [17:18:05] and a few fixes and additions in code [17:18:33] for the LVDC, the default pitch polynomial wasn't good enough [17:18:37] AS-203 is super light [17:19:06] and that mission didn't do a MRS, so it needs a bit of flag and presetting trickery to work [17:19:45] of course there is not much happening over all [17:19:58] it's fun to see more than 3Gs at orbit insertion [17:20:12] I have it at 13 m/s cutoff DV bias :D [17:20:42] haven't tested the engine restart yet [17:21:06] did that mission perform TLI? [17:21:53] not really, just tested coasting in orbit, then a short burn, and then more coasting [17:22:02] to verify you could safely do that for multiple hours [17:22:08] ah ok [17:23:28] orbit insertion at 7min13sec [17:23:31] pretty quick :D [17:24:19] yeah [17:25:02] im back home now, so I am about to try the latest commits. Anything in particular to test? [17:26:45] hmm, not really, maybe a launch or so [17:29:04] ok [17:30:30] haha 1st test went well, it didnt even liftoff :D [17:31:15] on purpose or not on purpose :O [17:32:11] I didnt switch off the EDS switch, but this is the Apollo 11 -30s scenario so maybe its something to do with that? [17:33:49] in older scenarios it might check the condition immediately, because I added an additional state in the ML [17:34:10] and then, also in older scenarios, I had the polarity of the EDS circuits inversed [17:34:33] must be that then [17:34:44] it might be fixed by changing something in the MESCs [17:34:57] MESC A and B, has EDABORT relay states saved [17:34:58] I guess all the Apollo 11 mission scenarios will get updated anyway [17:35:18] and it's only going to be a problem in certain old scenarios [17:36:34] can you try to fix those relays in the scenario? [17:36:37] if that is the only issue [17:37:03] EDSABORT1RELAY [17:37:04] and 2 and 3 [17:37:09] are probably 0 in the scenario [17:37:11] have to be 1 [17:37:21] in both MESCs, so 6 relays all-in-all [17:37:47] sure [17:40:10] those are the three wires that cause an auto abort if the vehicle breaks up. That's how I had read about it many years ago [17:40:40] that's why they need to be powered (1), and not unpowered (0) by default :D [18:07:10] morning! [18:10:06] hey Mike [18:11:53] hey [18:13:34] indy91, yep that fixed it [18:20:16] hey Mike [18:20:21] AlexB_88, nice [18:23:45] I fear a lot of old scenarios might be affected [18:23:52] didn't really expect that [18:24:03] anything saved after T-187s maybe [18:24:09] for Saturn V [18:25:37] the simpler fix might be to fix the ML state [18:26:17] having added a ML state makes it, in old scenarios, switch to the next one immediately upon loading [18:26:25] and that's when it checks the EDS condition [18:39:37] I guess you can simulate normal countdown holds a little bit better now [18:39:41] like Apollo 17 [18:39:49] you still need to edit the mission time in the scenario [18:39:59] but it might be possible to do that at that T-30s hold point [18:40:17] remove the hold flag in the scenario, edit mission time [18:40:21] and it might work? [18:43:01] oooooohhhh man I might see in the schematics where my problem with the restarts is [18:43:29] not in the NASSP schematics though, hehe [18:43:38] haha no, AGC schematics [18:43:57] yeah [18:44:21] so you have a lead? [18:44:34] so there's four flip-flops that latch incoming requests (one for each of LOAD, READ, LOADCH, READCH) [18:45:02] and then also a flip-flop that inhibits count cycles from happening, that gets set when any of your four request lines are high [18:45:28] the first four are written into at phase 4 of time 12, and make the MREQIN signal go high, which lets the monitor know that its request has been latched [18:45:51] but the count inhibiting flip flop is written into during phase 2 of time 12 [18:46:06] so say, for example, your request comes in during phase 3 of time 12 [18:46:38] one of the group of four will latch your request and set MREQIN high, making the monitor think that the AGC is about to execute the peripheral instruction [18:46:52] but the counter inhibiting flip-flop didn't get set, so it executes a count instead [18:47:17] and the monitor injects a bunch of stuff onto the write bus while a count is happening, totally corrupting the results [18:47:56] that sounds unhealthy [18:48:09] yeah [18:48:45] so I think I need to time my requests such that I know for sure that I've been asserting my request for the entire T12 [19:09:19] have you checked your framerate in Orbiter yet? [19:12:09] nope! [19:13:31] ideal would be above 60, 30-60 would be ok, much below 30 could be problematic [19:16:24] hmm, okay [19:28:34] alright, FPGA built, let's see if this has any effect [19:28:59] the good thing about this is that it should be immediately obvious when I have a build that works [19:29:26] it was pretty obvious that it didn't work yesterday :D [19:31:55] haha [19:32:01] that took minutes to see though [19:33:04] ah, so immediately with the first LR data [19:33:11] if I remove all of my halts and things normally, the RCS goes crazy [19:33:34] so I just need to fix things until my RCS stops freaking out, and then the LR should also be fixed in theory [19:33:46] or rather [19:33:49] not broken in the first place [19:38:33] hmmm [19:38:34] nope [19:38:40] RCS is still constant [19:39:09] constantly on you mean? [19:39:16] pretty much [19:39:23] why is the RCS suddenly a problem :( [19:39:25] it's holding attitude but just using all of the thrusters all the time to do it [19:39:28] it always has been [19:39:44] and it's related to the peripheral instructions thing [19:40:48] I originally put in halts around poking the ICDU data which helped [19:40:56] but that was more masking the problem than fixing it [19:43:03] yeah, got a random restart too [19:43:15] everything seemed to work ok at first, but now all the problems are becoming obvious, haha [19:43:24] heh [19:43:47] well, it's more that the problems that I tried to just cover up ended up coming back to bite me :P [19:44:10] yeah [19:46:44] not a good order of these things to happen, now that you are basically commited to making it work with NASSP [19:47:24] committed? haha [19:48:47] I mean, in Carl's blog I read that you will have a LM with lights instead of RCS to demo the DAP, haha [19:49:52] almost as good as a lunar landing with NASSP [19:51:16] oh boy [19:51:17] oh now that you are running NASSP, you should try the Aurora test programs if you get time [19:51:28] yeah, will do that eventually [19:51:36] it's a fun show in the LM [19:53:38] hmm, so if that wasn't the problem, then what could it possibly be [19:56:40] so you have a RCS issue and a LR issue [19:56:56] well, separately [19:57:02] yeah [19:57:19] the bandaids for the RCS issue sufficiently screw up timing such that the LR no longer works [19:58:06] it's all a related problem and the cause of the random restarts [19:58:17] all signs point to this being a logical error with peripheral instructions [19:59:16] which is about the last thing I can help you with :D [19:59:23] yep [20:02:15] can we not make changes to NASSP to make it more realistic and less hacky ways of getting it to work with the AGC are needed? [20:03:01] not unless you want to help design a whole bunch of circuit boards and make five or six more FPGAs :P [20:03:23] ah right, it wasn't just a problem of NASSP needing work [20:03:34] but the realistic solution is a hardware solution [20:03:35] the less realism is helping me right now [20:03:50] not enough apparently :D [20:04:42] eh, I've been vaguely aware of this problem since long before I tried to get things working with NASSP [20:13:44] okay, can confirm that it's not related to the fake input channels, because the problems still happen if I actually set the "real" switches [20:14:29] indy91, could the RCS potentially freak out a bit if the ICDU readings don't all come in at the same time? like if first CDUX gets updated, then a bit of time, then CDUY, etc. [20:23:21] seems unlikely given how little these are changing [20:23:54] yeah, probably not [20:24:16] can you get into any stable configuration with the RCS? [20:24:42] not yet [20:24:56] strange [20:25:08] and you are using the same scenario as before [20:25:27] so can't really be anything on the NASSP side [20:25:45] the behavior is that it is firing a lot? [20:26:48] like I said, the issue is that the monitor peripheral instructions are corrupting data somehow [20:27:04] I just can't figure out how [20:27:32] and yes, the first obvious side effect of this is incessant firing of the RCS, accompanied by random hardware restarts [20:28:06] that don't happen if I'm not performing any peripheral instructions [20:28:11] right [20:29:23] I wish I could help you [20:29:44] I can keep on filling the folder with demo scenarios as motivation :D [20:30:03] like, I haven't added anything with Sunburst yet [20:30:23] haha [20:30:30] for Sunburst I need to get downlink working apparently :P [20:31:07] and uplink, for the abort modes [20:31:22] pretty sure I can just use the DSKY logic for that [20:32:44] abort modes uplinked involved the unused keycodes [20:33:29] so you would need two cheaty DSKY keys :D [20:36:52] yes, I know, my DSKY logic can send whatever keycode I ask it to [20:37:33] ah, nice [20:38:09] I'd say LM-1 doing a contingency orbit insertion using P12 guidance equations would also make a nice demo [20:39:15] but anything that isn't a DPS failure would certainly please Don :D [20:42:31] good night! good luck with the search for the cause of the issues [06:26:11] morning! [06:33:32] thewonderidiot, found the cause yet? [06:34:50] nope! [06:34:54] it is completely baffling to me [06:35:00] the behavior looks fine in the logic analyzer [06:35:09] it makes me worry that there might be transients or something [06:35:22] however! I had a sudden realization that made all of the problems disappear [06:35:52] I can just use simulated erasable memory instead, and poke the memory directly in the monitor instead of going through a peripheral instruction [06:35:58] if I do that, everything works perfectly [06:36:10] only downside is it's using simulated memory instead of real erasable [06:36:26] but that also has several upsides [06:36:41] for one, the AGC is in a lower power state so we can leave it running for longer without it getting too hot [06:36:57] and also it means we won't be running our current switch module without the full monitor panel up for alarm monitoring [06:37:10] so we don't risk hurting the AGC by not seeing a potential failure [06:37:33] the landings are remarkably smooth now [06:37:46] awesome [06:37:51] so I'm going to commit all of this, and then move on to hand controllers [06:38:16] I also taught NASSP how to load ROMs into the monitor for rope simulation, so when you load a scenario now it also loads the correct program for that scenario [06:38:22] I guess you can limit using the erasable for certain, shorter demos [06:38:31] yeah [06:38:44] when we have the full monitor panel up we'll use real erasable (as long as it's still working) [06:38:52] and then when I go to NASSP I'll kick on erasable simulation [06:39:36] but yeah, just did a perfect P65 landing, sat on the surface for a bit, hit abort stage, and now I'm in a nice abort orbit [06:39:39] so now you are using our bad, mission dependant system of loading ROMs:D [06:40:01] 59.9k x 15.44k [06:40:10] very nice [06:40:20] haha yeah [06:40:40] so a couple of things I wanted to ask about [06:40:43] still need to change it in code when I want to run Zerlina [06:40:53] I can do that :D [06:40:57] so first, LM shadow [06:41:06] it appears when I am in external view, but I can't see it through the windows [06:41:20] hmm [06:41:24] and I don't see any options in the GUI that would obviously affect that [06:41:48] do you know what the different shadow modes are in D3D9Client.cfg? [06:41:58] I think I'll update to the latest version of Orbiter and the DX9 Client [06:42:15] so that I am using the same as you [06:42:20] cool [06:42:38] I hope you see the same; this is consistent between two computers and three graphics cards for me [06:42:50] none of the updates were really important for us, but maybe something is broken [06:43:15] I got an external GPU for my laptop so it can 100% definitely get a good framerate with the high res textures [06:43:26] you checked the advanced video settings? [06:43:35] so I get ~80fps in the main panel view and ~120fps in the LPD view [06:43:42] uhhh [06:43:44] ah, nice [06:44:05] wow I totally missed the advanced button [06:44:18] there are some options there [06:44:36] hmmm [06:46:03] okay I changed a bunch of things [06:46:09] let's see if any make a difference [06:47:21] if it's still not working then I'll send you a screenshot of my settings [06:47:39] sounds good! [06:47:43] so while we're waiting [06:47:45] cross pointers [06:47:53] yes [06:47:56] how do those work? should I be seeing movement on them? [06:48:19] yeah, same as tape meter [06:48:45] I used to see movement on them but now they're not moving and I'm not sure why [06:48:46] I wrote in my comment on your video which switches need to be set [06:48:55] hmm [06:49:45] those switches exist on both sides, guess only the CDR side is really relevant [06:50:04] I have all of those switches set [06:50:25] tape meters are moving from AGC, cross pointers remain stationary [06:50:52] what are you running, early P63? [06:51:04] right now yeah [06:51:11] maybe I'll see it do something during the maneuver? [06:51:19] when it rolls me over at 30k? [06:51:40] oh you should definitely already see something [06:51:49] at least in one axis [06:51:57] nothin' [06:52:12] it's possible I broke something [06:52:53] maybe you have to check the data flow of that [06:53:33] what is the data flow? [06:53:45] how do they work? [06:54:19] very similar to the tape meter I believe [06:55:11] rate err/mon in ldg radar/cmptr [06:55:32] yeah, have that [06:55:41] x-pointer scale only becomes important later [06:56:14] and mode select in pgns [06:56:30] yep [06:56:46] it does move if I switch to LDG RADAR on that switch [06:57:49] ah [06:58:12] ok, it actually doesn't work like the tape meter at all [06:58:16] haha [06:58:34] it's RR CDU error counter [06:58:42] oh wow okay [06:58:45] I don't have that wired up [06:59:04] alternative output to RR drive [06:59:32] maybe I'll do that next, that's easier than the hand controller [06:59:36] close to the surface the LR setting will give basically the same as PGNS [06:59:51] so maybe use that for now [07:00:05] it's raw LR data [07:00:31] still no shadow [07:00:33] definitely good enough as a tool for landing [07:00:43] weird [07:01:12] I'll update and test it, when you wake up I have the solution [07:01:18] hehe thanks! [07:02:02] I love the smoothness of these landings now [07:02:06] it's not self shadows [07:02:07] this is working extremely well [07:02:12] great [07:02:23] I have self shadows deactivated [07:02:34] oh heh [07:02:39] interesting [07:02:44] but I would assume it's in the same box in the settings [07:03:01] terrain mapping? [07:03:04] I'm on Projected [07:03:27] in 5 minutes in can tell you my current settings [07:03:41] kk [07:03:48] I will work on the crosspointer in the meantime [07:04:27] brb [07:08:41] I have terrain mapping projected [07:10:53] https://i.imgur.com/EHxrQdw.png [07:11:30] what do you have under Visual effects/general effects? [07:11:34] everything enabled? [07:12:17] uh [07:12:22] no [07:12:28] oh [07:12:33] I don't have Cloud shadows... am I a cloud? [07:12:46] also don't have Specular ripples or Local light sources [07:12:51] I don't have that either [07:14:28] and under General Effects? [07:14:38] vessel shadows, object shadows etc. [07:14:59] everything but local light sources [07:15:15] oooooh [07:15:22] is that it? [07:15:33] from Mr. jalexb88 himself in the DX9 Client thread [07:15:43] " [07:15:43] jalexb88's Avatar [07:15:44] [07:15:44] Join Date: Aug 2008 [07:15:45] Posts: 61 [07:15:46] Canada [07:15:46] Default [07:15:47] I have a minor issue with the self-shadows: When I set the terrain mapping to projected this works very well for the most part, except that the shadow is not visible from internal views. This makes it quite challenging for scenarios such as landing the LM on the moon as one relies a lot on the shadow for height perception. Using stencil mode is the only way right now to see your shadow from internal views." [07:15:52] oops [07:15:55] that text [07:16:07] aha [07:16:13] from May [07:16:24] so likely an issue with the latest version [07:16:34] should I downgrade then? [07:17:07] as he said, terrain mapping - stencil mode should do it [07:17:18] not sure how that looks though [07:17:22] probably fine [07:17:39] only one way to find out [07:18:08] About the cross pointer, that is one of the (few) things that goes through our CDU class [07:18:19] fictional channels 140 and 141 [07:19:05] and that should work like thrust or altm right? I just give you the total value requested in those channels? [07:19:32] hmm [07:19:34] not total [07:19:41] well I mean [07:19:49] whatever the AGC writes into CDUS or CDUT I pass along [07:20:01] oh [07:20:03] yes [07:20:07] CDUSCMD/CDUTCMD, rather [07:20:12] same as thrust and altm [07:20:42] yeah, that'll be easy to add :) [07:21:53] I guess FDAI error needles would be similar [07:21:56] throttle up [07:22:05] hmm [07:22:07] how do those work? [07:23:12] our fictional channels 174 to 177 [07:23:23] also very similar I would think [07:23:35] oh, through CDUXCMD, etc. [07:24:05] okay I need to write some generic code since these all work the same way, haha [07:25:12] weird, I thought that was only used for driving the CDU [07:25:47] it is [07:25:57] ICDU error counters is FDAI error needles [07:26:25] unless coarse align [07:26:42] but it wouldn't be driving the CDU unless you're aligning, would it? [07:27:09] EnableIMUCDUErrorCounters [07:27:39] if CoarseAlignEnable, then the signal is not coming through to the FDAI [07:27:49] I see [07:28:08] so you're not driving the IMU itself [07:28:17] the coarse align enable has to be on for you to do that [07:28:31] yeah [07:29:21] whoa there [07:29:48] I need to not look out windows after throttle down [07:30:13] okay, P64 [07:31:05] I can see my shadow! [07:31:10] just a little dot right now [07:31:14] yay [07:31:21] wow that really helps [07:31:27] the monthly launch window finally has a meaning [07:32:03] yeah that looks reasonable enough [07:32:05] the right sun angle is THE most important thing for Apollo launch windows [07:33:20] great that you got it working [07:33:25] no thanks to me, all to Alex :D [07:33:47] haha [07:33:57] thanks Alex! [07:34:04] and thank you for finding the message from Alex :D [07:34:44] whew, I'm feeling so much better about all of this now [07:35:19] yeah, that was a bit frustrating in the last few days [07:35:22] I will definitely have crosspointers and FDAI needles tomorrow... and potentially a hand controller [07:35:35] but no promises on the hand controller [07:36:20] interrupt injection will be a little bit harder to genericize [07:36:24] ROD switch might be helpful [07:36:41] hmm [07:36:42] for P66 [07:36:50] so that you can see throttle oscillations [07:36:55] on the joystick or? [07:37:28] would the ROD switch not already be working? [07:37:36] uhh [07:37:44] it's input bits, but I thought there was an interrupt involved [07:37:56] Minus and Equals on the keyboard [07:38:01] not numpad :) [07:38:06] hmm [07:38:15] not sure what interrupt it would be if not HANDRUPT [07:38:24] I thought it was HANDRUPT [07:38:33] but maybe not [07:38:42] oooohhhhhhh [07:38:57] it's the secondary DSKY interrupt isn't it [07:39:21] yeah [07:39:28] damn [07:39:29] just following it in the Systems Handbook [07:39:33] okay that one is extremely annoying [07:39:34] KEYRUPT2 [07:39:46] Trap 15B and all [07:40:01] I can do it, because I did it for the primary DSKY [07:40:05] but man that is an annoying one haha [07:41:01] my DSKY code is going to be changing a lot [07:41:24] oh noo [07:41:50] it's fine, I know how I want to structure it and if it goes according to plan I'll be able to inject all interrupts very easily after this [07:42:00] to be fair, that is something you should have seen coming :D [07:42:06] well [07:42:10] I guess, haha [07:42:22] KEYRUPT2 is a thing [07:42:26] in my defense, a few weeks ago I still thought NASSP integration was like a year away :P [07:42:34] same [07:43:46] alright, I've got a pretty solid game plan for tomorrow [07:44:06] this feels like a good stopping point for tonight [07:44:15] thanks for all the help, and goodnight! [07:44:25] good night! Dream of LM shadows :P [07:44:29] hehehe [12:46:53] hey [12:52:22] hey Niklas [12:53:45] doing a bit more AS-203 tweaking [12:54:12] it was actually launched from LC-37B, but our LC-37B is only compatible with the LEMSaturn (Apollo 5) right now [12:56:33] figured out the right insertion orbit, too, with a similar method as I used for the TLI presettings [12:56:41] derived from the planned IU state vector [13:00:27] it's pretty standard 72°, 100NM orbit, but the orbital plane is slightly different. Did a 15° yaw maneuver at IGM start which I didn't like. [13:02:17] I should be able to release that soon, just need to do a test flight up until the S-IVB restart [13:12:34] cool stuff [13:12:48] wonder why it did the 15 degree yaw thing [13:13:33] well, for me it did that [13:13:50] using the Apollo 7 inclination and descending node angle [13:14:12] then I derived the right numbers for AS-203 from the state vector and that was fixed [13:14:26] but still, the Apollo 7 numbers should have been really close [13:14:41] it must be the quick ascent to orbit that AS-203 did [13:15:08] launching to 72° must mean that at IGM initiation it's at a rather different location than Apollo 7 was [13:15:51] well both launched to 72°, but the IGM initiation location must be different [13:16:18] it keeps on going towards 72° until IGM start [13:17:33] which is not in-plane, inertially speaking [13:17:50] so that must be the difference. Inclination is a bit different from Apollo 7, descending node angle even more [13:21:41] right [13:23:34] never really thought before about the inclination/DNA being vehicle dependant for a specific launch azimuth [13:24:04] Skylab Saturn IB LVDC had a yaw program during first stage flight [13:24:18] I wonder if that keeps it more inertially in-plane during the later first stage [13:49:41] fun fact about AS-203 [13:49:46] it had a Q-Ball [13:50:05] that thing that normally is on top of the LET to measure angle of attack [13:50:22] so, as compared to Apollo 5, the nosecap had a tiny tip :D [13:57:00] does it have a boilerplate CSM? [13:57:10] nope [13:57:11] nothing [13:57:14] just empty [13:57:43] a few circuits from e.g. the EDS are wired to have a return signal from beyond the IU [13:57:48] but just for telemetry and testing [13:58:03] purely a S-IVB test [13:58:25] this was before Apollo 4, so this was the first test of a S-IVB restart [13:58:37] ah ok [13:58:44] and only a half attempt really [13:58:48] so do we have the appropriate meshes for that? [13:58:54] mainly to test pressurizations [13:58:59] we have a nosecap [13:59:16] looks like the same one as Apollo 5 [13:59:31] it should be different [13:59:37] but other than that, it looks quite good [13:59:53] panel isn't rendered, due to a "Unmanned" flag [14:00:03] but the CSM systems all exist anyway [14:00:14] just idle [14:00:18] right [14:01:37] it's just a quick demo anyway [14:02:24] I guess I can make something similar with AS-201 [14:02:31] that had a CSM, but no AGC [14:02:49] but Block I is still far away [14:05:29] yeah [14:05:57] oh, you were saying yesterday it was maybe possible now to use the mission time to delay launches? [14:06:48] is there a way to pause the mission time? Or do you add the length of the hold to it? [14:07:36] just scenario editing right now [14:07:51] the main countdown time should be in the LCC, or ML or somewhere anyway [14:07:55] right now it's in the Saturn [14:08:09] and we basically have hold points, but it's not holding the time yet [14:08:27] so what you can do is cause a hold, then edit the mission time in the scenario and remove the hold [14:09:51] oh, and AS-203 didn't really do a restart. The only reason I was thinking that was a "Engine Start On" in the sequence of events [14:10:04] they just repressurized everything and had it ready to do a restart [14:10:19] the only propulsive thing there will have been LOX venting I guess [14:11:49] and if you rally want to follow the real thing, have it blow up after 4 orbits :D [14:12:31] yeah, haha [14:12:56] blows up after 4 orbits, 2nd TLI opportunity is after 3 orbits. Design verified! [14:14:20] I guess I just let it do lots of LOX dumping, as per sequence of events [14:14:28] should raise the orbit quite a bit and deplete the LOX [14:19:30] yeah, no real restart, just the prep for one [14:20:03] including a bunch of acceleration due to LOX venting, LH2 venting, gas burner [15:09:29] AlexB_88, pushed the AS-203 scenario if you want to try it [15:09:40] still under broken scenario/historical missions [15:10:00] scenario starts as before, at T-100s [15:13:35] "as before" meaning we had a AS-203 scenario, just veeeeeery old [15:17:31] ok [15:18:54] 5.5Gs at S-IB burnout, 3.5Gs at orbital insertion [15:18:55] for say a TLI+90 is that TLI TIG +90 or cut-off +90? [15:19:16] good question [15:19:44] I only remember that I researched that and hopefully got it right for the MCC, haha [15:21:50] not even sure if I got it consistent. Or if they did it consistently for the real missions [15:22:00] how do we do it for 11... [15:22:30] we use [15:22:42] TLI ignition + 90 minutes as the impulsive TIG [15:23:48] so the actual TIG might be a few minutes earlier than that, with a long burn [15:25:48] ah right [15:26:19] although I can't 100% derive that right now with the actual Apollo 11 times [15:27:59] Operational Abort Plan says the Abort TIG should be at 90 minutes after TLI cutoff [15:28:22] of course there is also TLI burn cutoff and the actual definition of TLI, which is 10 seconds after cutoff [15:29:23] althought it also says that it should be P37 compatible [15:34:29] I'll listen to the RETRO loop again to try and verify this :D [15:36:47] why were you asking? [15:36:54] is the TIG off from what you expected? [15:40:16] Im was trying to calculate the Apollo 15 TLI+90 for fun, with my Apollo 15 pre-TLI scenario [15:41:13] I used the TIG +90m and that gave the same TLI+90 TIG as on the block data schedule within a few swconds [15:41:17] secons* [15:41:35] ah, nice [15:41:38] my keyboard hates me today [15:41:52] haha [15:41:55] either that or I cant type :D [15:42:37] so it seems on 15 at least, they used the TLI TIG + 90 [15:44:41] the TLI+5 is 7:44 [15:44:47] that also would be ignition [15:44:51] impulsive this time [15:44:55] because P37 input [15:53:16] yeah, I can't really figure out the exact numbers they used for this [15:53:20] I'll try to find out [17:11:47] oh I just found something in the Apollo 12 Saturn Flight Manual [17:12:33] indy91, "timebase 6 will not initiate automatically if a guidance reference failure has occurred" [17:14:50] I wonder if this was a change after Apollo 11 [17:15:25] I say that because Apollo 12 backup TLI checklist has all the procedure for manual TB6 initiation [17:15:29] Apollo 11 does not [17:20:01] too bad we dont have the SA-506 flight manual [17:28:30] morning! [17:41:25] hey Mike [17:41:57] AlexB_88, yeah, if GRF disables normal TB6 then Apollo 11 had no chance for TLI [17:43:44] the mission rules have a direct no go for specific state vector errors [17:47:45] so maybe in the case of a guidance reference failure, there should be a check to prevent the LVDC from going to TB6 in on Apollo 12 and later [17:48:03] I mean automatically going to TB6 [17:48:23] Okay, I'm getting all my branches up to date again. Might fly Apollo 8 this evening. [17:48:37] I'm assuming my old scenario isn't going to work anymore. [17:49:38] AlexB_88, yeah, probably [17:49:43] Thymo, depends how old [17:50:23] even the NASSP 7.0 release scenarios are mostly still working [17:50:42] Oh haha. So old I don't even have them on this computer anymore. xD [17:50:49] They're still on my old drive. [17:50:54] well, T-4h scenario it is :D [17:51:01] Yeah. [17:51:21] if you make it to the Moon then you can test my MCC changes [17:51:23] Don't feel like digging that drive up and bodging it in my system. [17:51:28] On 8? [17:51:30] unless you prefer non-MCC missions [17:51:45] yeah, there were basically no updates from 7.0, so I started updating it [17:51:50] but only got to mid TLC [17:52:05] not all tested. Launch to MCC-1 is definitely tested [17:52:40] I can't math. So I'd love someone to do the Orbital mechanics for me. If I do it that Venus flyby might become a reality after all. [17:53:16] First I need to fix a bunch of merge conflicts in my branch I never bothered to merge. [17:53:16] haha, maybe your S-IVB ends up there [17:53:56] Me too if I'm not careful [17:54:33] you easily have the DV [17:55:10] Yep, but I'm not counting on the AGC to get me back. [17:55:49] Unless someone pathed it to make the SV work out there. [17:55:56] s/pathed/patched [17:56:11] nah, shortly after the Moon you get into scaling issues, as you will know [17:56:25] I remember that we looked into that a while ago [17:57:02] Should be fixable if we yank a lot of unneeded stuff out of the rope [17:58:48] AlexB_88, I guess on Apollo 11 you would do a IU state vector update with a GRF and then the LVDC is still allowed to start TB6 [17:59:02] right [18:00:08] should be safe [18:00:16] you can just go TLI inhibit until the uplink is in [18:00:30] I really should try again to implement that uplink... [18:01:41] I guess it already does an IU SV update anyway [18:02:04] yeah, but not as I would like it [18:02:24] and definitely works differently than a real one would [18:02:31] the LVDC is not quite as smart as the AGC [18:02:42] you need to uplink a SV some time in the future [18:02:44] for some* [18:03:00] and when that time arrives it then changes to that SV [18:09:56] monitor FPGA has been updated to add all five CDU output counters. gonna get breakfast and then test, and then hopefully will have movement on the cross pointers and FDAI needles :D [18:11:04] great. is it all going into NASSP in SetOutputChannel? [18:11:15] it will, yeah [18:11:20] good [18:11:24] indy91: Did you ever put the instrumentation bus in the CSM? [18:11:40] the AGC bridge receives the number, masks off the "new value bit", and passes that in to NASSP via those ficticious channels [18:11:43] Around when you implemented the first ECS sensors 7 months ago. [18:12:55] I think I did some of that, yes [18:13:11] I'm sure there is still a lot to do though [18:13:46] I wired InstrumentLightingESSMnACircuitBraker and InstrumentLightingESSMnBCircuitBraker to Main Bus A and B [18:13:47] What is InstrumentationPowerFeeder exactly? I think that's something you added. [18:13:57] and those power InstrumentationPowerFeeder [18:14:04] with Main A and B power [18:14:30] like so often in the CSM, one Main A and one Main B CB powering a system [18:14:32] Okay. I have the InstrumentationBus in my code. So that's gonna be fun. [18:14:41] I wired everything on panel 276 to that bus. [18:14:47] But you wired it to that power feeder. [18:14:53] yeah [18:15:08] your bus was powered by the two breakers? [18:15:13] Is that power feeder someting that really exists on a drawing? [18:15:16] or how did you set that up [18:15:25] No my bus powers those 4. [18:15:46] I'm not 100% sure how that bus was powered, I know it's on the drawings though. [18:16:06] let me check [18:16:29] it's been a while :D [18:16:59] Yep, same for me. Should have merged this way earlier. It has some nice changes to the power system. [18:17:53] I think what I saw was drawing 7.1 [18:18:09] those two 2 CBs powering the 4 panel 276 CBs [18:19:25] I am not seeing one instrumentation bus, I'm seeing many in the Systems Handbook [18:20:09] One sec. Let me pull it up [18:20:54] I did one other power related thing since then in the CSM, but one step at a time [18:21:46] I thing the feeder and bus do the same. But I'm in the middle of resolving merge conflicts so I can't really use search. [18:21:59] oh yeah, I am sure they are the same thing [18:22:08] My bus is a power merge, now looking what it is merging. [18:22:16] Probably mna and mnb [18:22:18] well, mine is, too [18:22:19] haha [18:22:26] name difference? [18:22:33] Most likely [18:22:42] I chose bus, you chose feeder. [18:22:52] if that was actually considered a bus, then your version is superior [18:24:27] Is the HeliumNitrogenPressMeter still a thing? [18:24:44] but I am only seeing buses derived from the panel 276 breakers and from the SCE [18:24:46] uhh [18:24:55] Or was that removed from the code? in satswitches [18:24:57] SaturnSPSHeliumNitrogenPressMeter SPSHeliumNitrogenPressMeter; [18:25:09] What does it wire to? [18:26:02] nothing I can see [18:26:04] Okay. So your feeder is wired directly into main A and B without a breaker in between? [18:26:10] so it will on the general GaugePower [18:26:15] no [18:26:24] Mine is wired to InstrumentLightingESSMnACircuitBreaker and B [18:26:58] InstrumentationPowerFeeder.WireToBuses(&InstrumentLightingESSMnACircuitBraker, &InstrumentLightingESSMnBCircuitBraker); [18:27:10] Great [18:27:10] in satsystems [18:27:15] We wire to the same source [18:27:24] that makes sense [18:27:25] good job us [18:27:29] yay [18:27:43] I guess I wired a bunch of instrumentation stuff when I implemented the SCE [18:28:07] Well I was doing the same thing around the same time but with the goal to remove GaugePower. [18:29:03] yeah [18:29:06] good goal [18:29:20] the panel 276 breakers are doing very little right now [18:29:28] one meter is wired to Panel276CB2 [18:29:31] and that's about it [18:29:32] They do a lot in my branch [18:29:49] then that's what your branch will be the most useful for [18:30:29] One problem. So far I see one special case where I used the InstrumentBus as a place holder so it didn't use GaugePower. [18:30:44] And that is the helium nitrogen pressure meter in the up position. [18:31:12] Center uses 276CB3, down uses 276CB4 [18:31:48] I think the better solution for that is to have it in the SPS propellant code [18:31:58] not in QueryValue, or wherever you have that [18:32:19] I wire them in QueryValue right now [18:32:41] But that can be changed if necessary. [18:33:27] yeah, I think QueryValue should stay as we have it [18:33:34] and put the CB check there where the sensor is [18:33:37] SPS propellant [18:33:39] so it calls e.g. [18:33:40] Sat->GetSPSPropellant()->GetHeliumPressurePSI(); [18:33:53] and GetHeliumPressurePSI() only returns the right value if the CB is powered [18:33:55] otherwise 0 [18:34:41] Okay. I'll take a look at that after I merge this. [18:34:57] So it will check the CB in QueryValue after the merge, but I'll change it. [18:35:08] sure [18:35:21] not important for the merge [18:35:48] So far I see I wired the cyro tank meters row to the instrument bus too. [18:36:01] But I think those 2 things are it. [18:37:12] But at that point it looks like I was doing a simple search and replace on GaugePower->InstrumentBus. Just so you have a way to turn it all off until I could find a proper source. [18:37:32] right [18:37:52] well merge it so that it works and then mainly focus on the four panel 276 CBs and wire stuff to those [18:38:02] the first two of those CBs actually power buses [18:38:18] no [18:38:19] all of them [18:38:42] two of them in the SM [18:38:54] I'm gonna stick to InstrumentBus for now so it will keep compiling. [18:39:09] And while I was typing that VS decided to crash... Great [18:42:00] Let's compile and see what works [18:43:33] it's your choice, but I would probably have started from scratch. I prefer starting over to complicated merges, haha [18:44:05] any branch I have that I didn't touch for more than a week or month I might as well delete [18:45:05] I can always start over if it doesn't work. But if I make it work it will save a lot of time tracing the drawings to see where power's coming from. [18:45:21] yeah [18:46:48] getting rid of SwitchPower and GaugePower seems like a good project, that also wouldn't be disrupted (too much) by any other work [18:49:50] and when you get to it, I need to make you aware of something on drawing 3.2 [18:50:10] What's that? [18:51:25] so recently I noticed that EDS bus 2 didn't get any power [18:51:44] the breaker for that is called BAT C BAT CHGR/EDS 2 [18:52:15] I see it [18:52:22] It's not wired huh? [18:52:35] and it can have current flowing in two directions [18:52:45] normal is [18:52:58] So the EDS can charge bat c? [18:53:18] Bat C -> BAT C PWR ENTRY/POST LANDING -> BAT C BAT CHGR/EDS 2 -> EDS2 [18:53:23] but [18:53:28] when the battery gets charged [18:53:38] it's going [18:53:51] to A and B [18:53:57] Battery Charger -> BAT C BAT CHGR/EDS 2 -> BAT C PWR ENTRY/POST LANDING -> Bat C [18:54:06] see the issue? [18:54:16] we can't really do that two direction thing very well [18:54:37] so what I did was add some code in BatteryCharger::Charge [18:54:53] so that the stuff gets rewired, depending on charging or normal operation [18:55:30] that way both modes are working [18:55:34] but it needed that special code [18:55:40] just something you need to know about [18:56:16] if you are ever seeing that and wondering how we handle that [18:56:19] We also need to take into account that EDS2 can be powered directly from the battery charger if BAT C BAT CHGR/ EDS2 is disconnected. [18:56:26] right [18:56:44] Does that work already? [18:57:10] hmm, kind of [18:58:17] I'm not sure if that supposed to work at all. How much current is the EDS supposed to pull? I'm pretty sure the charger can source enough current to supply it, but you never know. [18:58:35] yeah [18:58:56] so I do think that would be working right now [18:59:04] Battery Charger -> BAT C BAT CHGR/EDS 2 -> EDS2 [18:59:10] is when the charger is on [18:59:39] but I am sure there are some cases where one CB is in the chain of CBs that shouldn't be there [18:59:56] But that doesn't work if you pull that breaker if I'm not mistaken. [19:00:07] ah yes, you are right [19:00:10] Because then the breaker should show as unpowered. [19:00:26] BAT C BAT CHGR/EDS 2 shouldn't be needed, if battery charging is on [19:00:29] or so we think [19:00:35] definitely shouldn't matter [19:00:40] but it does right now [19:00:48] So maybe a PowerMerge between that breaker and charger bat c output? [19:01:03] Then it would be as if it is wired in between the breaker and the charger. [19:02:29] yeah. But as you can see the Main Bus Ties also play a role [19:02:41] so maybe something for you to research and improve at some point [19:04:38] I just wanted to make it work good enough for EDS Bus 2 to work [19:04:43] By the way. This drawing is of way better quality in CSM-114. It's all on one page as opposed to CSM-104. [19:05:02] yep, that's what I am looking at [19:05:07] which can be dangerous [19:05:11] J-type CSM [19:05:35] There are some minor changes it on this drawing. [19:05:38] but it's the copy with the best quality [19:06:00] In CSM-104 they label it "To EDS 2". In CSM-114 "To EDS Bus" [19:07:21] both a bit incomplete [19:07:23] EDS Bus 2 [19:11:09] well, focus on this instrumentation power stuff first. The EDS CB might be a bit more complicated. [19:11:22] Yep [19:11:36] but maybe not as complicated as you merge process :D [19:11:39] your* [19:11:45] I'm almost done. [19:12:23] 3 undeclared identifiers and some access protected member stuff [19:12:30] 1 of them was that powerfeeder [19:12:59] Now I'm looking at what CBs the H2OQuantityMeter is hooked up to. [19:13:49] By the way. Does reverse tunnel power from LM->CM work? I scrolled past the diagram, looks possible. [19:13:59] Obviously [19:14:35] it does not [19:14:54] Adding that to the list [19:15:05] but I'm pretty sure we would just need to get the Main Buses powered through those the LM power CBs from the LM [19:15:19] might be possible without too much effort, but I don't really know [19:15:28] I guess so. [19:16:15] But I'm still quite unfamiliair with the LM EPS (well the whole thing really). Seeing X LUNAR BUS TIE on my screen still scares me a little. :P [19:17:57] I haven't done super much with that either, it was mostly dseagrav [19:19:01] most of the fine detail wiring in the LM is done though [19:19:18] it helps when there are only like 3 CBs involved in instrumentation [19:21:44] Okay, so as far as I can see. Whenever the LM CDR bus is powered, there is nothing stopping the CM from drawing power from it through the tunnel connector into the LM PWR bus. [19:22:30] I think in the movie they mentioned they had to modify some stuff. But it looks like drawing power from the LM is as easy as throwing the LM PWR switch to CSM. [19:25:45] uhh [19:25:48] I don't think so [19:26:13] oh you mean how it actually worked [19:26:13] yes [19:26:30] it wasn't that difficult, just the right switch and CB configuration in CSM and LM [19:27:03] powering the Main Bus(es) from the LM [19:27:11] and the battery charger with the Main Buses [19:27:17] then the* [19:27:50] so we only need to think from one main bus (LM) to another (CSM) [19:28:40] We can go one step further and incorporate the massive losses from charing the CM batteries with the LM batteries. [19:29:09] We need to if we want to have a realistic charge level on 13. Otherwise we'll have too much power to spare. [19:31:47] most of the magic there (in our case) happens with PowerDrainConnector, PowerDrainConnectorObject, CSMLMPowerSwitch::SwitchTo and LEM_XLBControl::UpdateFlow [19:32:17] and some connector stuff [19:46:19] Hehe, I wondered why git wanted to remove my friend class declaration in my merge. [19:46:46] Now it doesn't work anymore. the SPS pressure meter can't access the breakers now. :p [19:47:22] speaking of things not working, now none of my output counters are working :D [19:47:52] Great! [19:49:07] I'm thinking if marking all these classes a friend is such a good idea. Those classes can then also access all private members. [19:49:30] Maybe it's better if we just mark CBs and stuff public and remove all the friend declarations. [19:52:00] aha, found my bug [19:52:47] Thymo, one project at a time, or you never get anything in the state to be merged. I have vast experience with that mistake, so I should know. [19:53:03] hahahaha [19:53:59] Hahaha. You just hit a sensitive nerve. [19:54:32] But I would agree, we have too many friend classes [19:55:01] I've worked a bit more with granting access to subsystems via functions [19:55:16] so, GetIU()->GetEDS()->SetRandomRelay(true); [19:55:38] but for our large number of gauges and switches that is probably not the right way [19:55:53] it would just be as many functions like that as friend classes [19:58:03] So let's do what already has been done dosens of times in the past. Comment it with "We should probably change this in the future" and leave it for 10 years. [19:58:14] if only 10 [19:58:30] When was initial commit? Since then. :p [19:58:34] AGC code has that kind of thing as well :D [19:58:57] I emailed Ron a while ago to ask if he could remove a unused header a while ago. [19:59:14] He commented it out. So it's still there "Just in case" [19:59:36] hahaha [19:59:43] That header wasn't used for multiple years. You never know. [20:00:32] almost worse than your Linux kernel merge [20:01:21] Haha. "Fix whitespace". And the 4 people proceeded to give their opinion on it. [20:05:23] hehehe [20:07:37] indy91: Can you pull up drawing 4.5 for me? [20:17:25] sure [20:17:48] Section F5 [20:18:28] Those two transducer breakers. Are those tied together in ECSWastePotTransducerFeeder? [20:18:28] yeah [20:18:57] Cool, then I don't have to create them. [20:19:19] the yeah was for the "Section F5" [20:19:28] bad timing, same second [20:19:33] Ah [20:19:50] but the answer is still yes [20:19:56] Sweet [20:19:57] now that I looked at it [20:20:08] I even made the sensors there already [20:20:18] probably when I worked on getting telemetry more complete [20:21:18] ECSWastePotTransducerFeeder.WireToBuses(&ECSTransducerWastePOTH2OMnACircuitBraker, &ECSTransducerWastePOTH2OMnBCircuitBraker); [20:21:28] in satsystems are all those WireToBuses [20:21:56] 6 of them for instrumentation so far [20:31:31] Build succes :) [20:38:58] okay, I think my cross pointers are working! FDAI error needles just sort of head to the corners and stay there [20:40:02] Nice [20:40:27] Merge is complete now. [20:40:44] 1.2 million additions and 550.000 deletions. [20:42:20] indy91, did the MPL change on the later missions? Apollo 15 flyby seemed to be targeted for 174 W [20:42:41] it did [20:42:55] for certain latitudes [20:43:02] not all 165°W anymore [20:44:50] already changed on 11 [20:45:35] uhh [20:46:30] in the Apollo 10 operational abort plan the MPL is all 165°W [20:46:43] but in the prelaunch mission operations report it is already as it will be later [20:47:30] oh weird [20:48:01] need to look at some launch window documents [20:48:23] northerly landings at the nominal time would already land at 175°W [20:48:35] that would be launch day May 23-25 [20:49:52] oh and on Apollo 15 we have RTEMaxReturnInclination = 80.0*RAD; [20:50:06] but for the flyby I find that 40 gives closer to the real DV [20:50:32] maybe the other aborts used the higher return inclination? [20:52:04] that's just the maximum [20:52:14] early missions restricted it to 40° [20:52:27] right [20:52:32] later there were no restrictions, but it doesn't calculate well beyond certain inclinations [20:52:39] so I put 80° [20:53:01] I think retrograde was still considered bad, so the real restriction would be 90° I guess [20:54:17] indy91: https://github.com/dseagrav/NASSP/compare/Orbiter2016...Thymo-:CM_EPS_fixes Would you like this to be merged already? [20:55:03] it's late, if you are happy with it do a PR and I'll look over it tomorrow and merge it [20:56:06] I see a couple of places that could use another look. But most of it is good for a merge. [20:56:21] sure [20:57:03] good night! [20:57:08] night [20:59:58] oh jeez, channels 0174 through 0176 are kinda mangled [20:59:59] okay [21:00:05] that's why my FDAI needles don't work [21:12:57] there we go! working needles :D [21:15:33] nice! [21:18:39] I think that just leaves the hand controller [21:46:46] AlexB_88: Weren't those new suit compressor sounds added a while ago? [21:47:35] added into code about 1-2 months ago [21:47:45] but the sound files themsleves have been around for longer [21:47:48] I think I found a bug. [21:47:57] I know, I found those on the old forum. [21:48:19] The compressor sounds stays running if you turn the compressor off and stay on the same panel. [21:48:19] oh the stop/start sounds [21:48:28] Yeah [21:48:41] The sounds stays running until you switch panels. [21:48:43] those are not the files from the forum [21:48:51] Oh, new ones? [21:49:04] its the same single file but with a play on volume/frequency [21:49:37] see the FadeInOutSound class [21:49:51] it was added recently to create that effect [21:50:31] I remember reading about it in an issue [21:51:22] https://github.com/dseagrav/NASSP/pull/465 [21:51:44] Yup [21:53:11] yeah I have seen that issue too, the sound seems to not spool down until you switch panels [21:55:30] I'll take a deeper look tomorrow. [21:56:11] I want to do a bit more work on the EPS, after that I'm grabbing a beer and watch some DS9. [22:07:13] .tell indy91 PR is up. [22:07:46] That branch was started in 2017. I'm surprised it merged so easily, just one evening. [00:22:59] ! [00:23:15] I think I just got generic, prioritized interrupt injection working [00:23:48] at the very least, with the refactored code I can still inject KEYRUPT1 [00:23:53] but does KEYRUPT2 now work... [00:24:48] yesssss [00:24:59] works like a DSKY in Comanche, program alarms in Luminary [00:25:23] which means the ROD switches should now work [00:25:40] now I just need to add in hooks for handrupt and downrupt [00:56:14] handrupts successfully injected!! [08:39:06] Morning! [08:39:14] thewonderidiot: Sounds great! [12:03:56] Thymo, PR is merged [12:04:47] Thanks [12:09:31] hey [12:10:46] hey Alex [12:14:54] early Systems Handbooks! Whenever you are not finding something, look there! [12:15:08] I figured out which relays cause the GRR and liftoff signals to the AGC from the IU [12:15:13] AS-501 Systems Handbook [12:15:42] just like the LM-1 one had some info that the LM-8 one didn't [12:16:28] nice [12:16:53] it is the same signal as the IU gets for liftoff after all [12:18:37] I found it when I was looking up how the LET was jettisoned on the unmanned missions [12:18:55] turns out it's a switch selector event from the IU to the programer in the CM [12:19:37] has the best IU/CSM interface drawing I have seen so far [12:21:18] IU also commanded the LV/SC separation [12:21:34] on all AS-202, 501 and 502 I guess [12:33:46] just tried AS-203 [12:33:58] that was a quick ride to orbit! [12:35:23] should that not be in WIP scenarios rather then Broken? [12:36:05] yeah, probably [12:36:34] I made a AS-202 one as well, but without Block 1 AGC and Programer that is a bit difficult [12:36:45] interesting orbit though. Suborbital, let's SPS do the restz [12:36:50] and 105° launch azimuth [12:37:25] interesting [12:37:37] 6800 m/s at cutoff [12:37:44] but 4° flight path angle [12:37:52] so apogee is quite high [12:38:00] lots of time for the CSM to start doing things [12:38:14] right [12:39:23] maybe I can set it up like a manned CSM [12:39:31] so that you can already fly it [12:49:01] minor issue I found in the RTCC MFD: when you specify an inclination in the RTM, it says enter 40D or 40A in the comments above the box, but what actually works is entering 40 for D or -40 for A [12:49:49] well not just 40, any number I mean [12:50:22] I guess what I mean is just the comment that needs clarification [12:50:44] "Choose the desired inclination (X°A for asc, X°D for desc):" [12:50:52] does 40°A not work? [12:50:56] it says ° [12:51:07] nope just 40 or -40 [12:51:16] 40A doesnt seem to work [12:51:21] no [12:51:23] 40°A [12:51:25] with the ° [12:51:31] as it says in the comment [12:51:34] ah havent tried [12:51:40] if (strcmp(dir, "°A") == 0) [12:51:41] { [12:51:41] ((ApolloRTCCMFD*)data)->set_EntryDesiredInclination(-inc); [12:51:50] I made it so that that works. Could be broken of course [12:51:58] but I did not implement 40A or 40D to work [12:52:01] only with the ° [12:52:03] I dont even think my keyboard can do that symbol [12:52:15] seriously? :D [12:52:38] oh wow [12:52:42] unless there is a special combination that is needed [12:52:45] it might actually not be on QWERTY [12:52:54] it is on my German keyboard [12:53:05] Shift and then the button above Tab [12:53:30] thats ~ on mine [12:53:33] yeah [12:53:37] I hadn't considered that [12:53:50] so I'll make that input more international :D [12:54:21] I wouldn't even know what to do without that symbol on my keyboard [12:54:24] I use it fairly often [12:54:55] haha [12:55:16] I always wondered how the heck is he doing that symbol? :D [12:57:03] https://upload.wikimedia.org/wikipedia/commons/thumb/3/36/KB_Germany.svg/1920px-KB_Germany.svg.png [12:57:43] explains why I have seen 40 DEG written online so often [12:58:00] "Choose the desired inclination (e.g. 40A for asc, 40D for desc):" [13:06:06] I wonder how Sunburst reacts now that it gets a GRR signal [13:27:07] hmm, doesn't seem to read it [13:31:36] so I think there was no IU to LM connection on Apollo 5 after all [14:51:33] I guess they had it already running [14:53:12] I was fooled by the "automatic detection" [14:53:32] Sunburst is monitoring the acceleration [14:53:43] if it detects 1.1G or more then it starts the liftoff program [14:53:58] we have that disabled, because it sometimes got triggered at scenario loading [14:54:10] might be ok now with the improved touchdown points [14:54:26] the alternative method is a V65E uplink [14:54:46] on the real flight both were done [14:55:26] we just do the V65E, via the MCC [15:35:02] makes sense [16:28:30] so I am testing my post-TLI Apollo 17 scenario. Used a fresh RTCC MFD and used the MPT to build maneuvers up to DOI-2. Landing is 2 seconds off from the flight plan...pretty amazing [16:28:40] and thats with the delay [16:31:06] oh but it gets better, I forgot to target 40000 ft instead of 50000 ft for DOI-2 [16:31:12] now its 1 second :D [16:32:09] well the specification for the J-type missions is +/- 2 minutes, so that seems about acceptable :D [16:33:05] yeah [16:33:21] that REV-2 crossing display in TLMCC option 4 really helps fine-tune it [16:33:38] REV-2 time* [16:35:12] yeah [16:37:38] now actually fly it and see if it still as accurate [16:37:42] that's the real measure [16:42:12] true [17:02:55] morning! [17:25:35] hey Mike [17:26:07] hey [17:26:28] I got generalized interrupt injection working, so I can send in both KEYRUPT2 and HANDRUPT now [17:26:41] so I think things are juuuuuust about done [17:26:57] FDAI error needles are also working perfectly, but cross-hair pointers not so much... still trying to track that one down [17:27:31] I learned last night that flying in P66 is hard and I have had several good crashes :P [17:28:08] nice, haha [17:28:16] what's with the cross pointer? [17:28:23] it just doesn't move much [17:28:47] hmm [17:28:56] I'm wondering if the AGC is sending counts to it faster than my framerate sometimes [17:28:57] in early P63 it would be full scale high [17:29:11] which would make me drop some counts [17:29:43] when I get home tonight I'm going to try putting a queue on those counters, such that I'm able to capture all of the writes that happen [17:30:16] yeah, sometimes it is, but sometimes I don't have any vertical movement at all [17:30:21] it's not completely consistent [17:30:32] yeah, sounds more like a problem on your side then [17:30:35] oh it is [17:30:43] all of these problems are on my side, haha [17:31:10] I'm not sure what framerate would have to do with it though [17:31:28] well [17:31:29] the data comes into CDU::ChannelOutput [17:31:32] yes [17:31:46] but I only can call that function once per frame for each channel [17:31:56] unlike the virtualagc which can call it many times in a timestep [17:32:14] ah, I see [17:32:33] so if, in a 1/60s window, the AGC writes to the output counter twice, I would only get the second [17:32:39] right [17:33:27] that's the only thing I can think of [17:33:40] unless there's some synchronization problem with other channels [17:34:04] mainly the bit in channel 12 that enables the error counter is relevant [17:34:23] should be on the entire time during a descent [17:34:35] yeah, I'll have to make sure that it is [17:34:43] if it toggles at all I could be losing some counts that way [17:35:38] I'll figure it out. that's the last big issue and I have a week :) [17:35:59] the other small issue I have is that looking out the window in late P63 can make me crash [17:36:11] so I just need to stay focused in the main panel view until P64 starts, haha [17:36:40] crash in what sense? [17:37:01] in the surface or the desktop (CTD)? [17:37:02] crash in the sense of the LM flipping upside down and burning me into the surface [17:37:11] that sounds bad [17:37:18] I realized what's causing that [17:37:30] the framerate in each individual view is quite good [17:38:01] but switching views takes quite a bit of time, so there will be a frame or so that takes 100ms+ [17:38:16] yeah, that's causing us issues as well [17:38:17] which causes a bad radar reading [17:38:25] which is catastrophic during late P63 [17:38:29] right [17:38:38] I'm pretty sure we could improve that, but probably not in time [17:38:44] haha yeah [17:38:54] we are not doing the most efficient way [17:39:02] I've been burned enough times that I am fairly confident I won't make that mistake during the demos, haha [17:39:31] what we really need is a 3D virtual cockpit with head tracking :D [17:39:43] yeah, haha [17:39:55] using the outside view for the whole thing would be the other solution [17:40:28] mmm, possibly yeah [17:41:05] I guess time acceleration is out of the question [17:41:10] haha yeah [17:41:19] I don't have an overclock switch on the AGC :) [17:41:29] I meant the opposite [17:41:40] hm? [17:41:43] but you don't have such a switch either [17:41:55] 0.1x time acceleration for the panel switch [17:41:59] oh [17:42:03] right [17:42:08] button R [17:43:36] so anyways, now that I have the ACA and ROD switch working, I wanted to ask about landing procedures [17:44:02] first, what's the best reference for "how" to fly P64 and P66? [17:44:34] hmm [17:45:25] the AOH has an annotated checklist [17:45:29] that can already help [17:45:38] ah cool, I'll check that out [17:46:06] so next question... in P64, if I want to redesignate [17:46:30] how long should I move my hand controller for? do I just push it a bit, let go, and then wait to see what the response to that input was? [17:46:36] or do I hold it until the angle reads what I want? [17:47:09] https://de.scribd.com/document/66115251/Apollo-Operations-Handbook-LM-5-and-Subsequent-Vol-II [17:47:22] that's the only source for the LM-2 AOH Volume II I have found [17:47:26] LM-5* [17:47:54] which is important, version differences and all [17:48:06] well first you need to press PRO [17:48:10] after P64 starts [17:48:14] that enables LPD commands [17:48:37] haha yeah, that took me a couple of landings to figure out [17:48:51] I thought my hand controller was broken and spent lots of time studying inbits :P [17:48:53] I think the AOH explains that quite well [17:49:01] you just do short deflections [17:49:14] the LGC will align the window with the current landing target [17:49:31] so on the marking is where you will land, both in pitch and yaw [17:49:57] in pitch it does 0.5° per deflection [17:50:00] in yaw 2° [17:50:10] that's Luminary099, later it's 1° each [17:50:19] not sure how much later, haha [17:50:36] hmm, okay [17:50:49] when you say on the marking [17:50:55] but if you already know you want to go much further then you can do multiple deflections after each other [17:51:02] in the LPD view [17:51:09] the pitch scale [17:51:22] I should be taking the angle displayed on the DSKY and looking at that vertical mark, right? [17:51:29] yeah [17:51:45] probably starts you at 60 something and quickly goes into the viewable range [17:51:54] yep [17:52:01] okay, so I'm doing that right :) [17:52:21] one to few short deflections [17:52:25] then wait for reaction [17:52:28] right [17:52:45] great [17:52:48] so then next question [17:52:49] we used to have trouble with doing that with a joystick [17:52:56] oh? [17:52:56] until you fixed something in the Virtual AGC [17:53:01] oh haha [17:53:13] perfect [17:53:23] maybe the timing of the interrupt or so [17:53:24] hopefully the real AGC also does not have that problem then :) [17:53:33] what was the problem, exactly? [17:53:44] it didn't take LPD commands all the time [17:53:51] ah [17:53:58] numpad could do null, deflection, null very quickly [17:54:01] so there it worked [17:54:14] I'm definitely getting response from the joystick [17:54:37] I did a test run last night where I managed to get my LPD angle up to 28 degrees, which I never saw without redesignations [17:55:42] right, so, next question. when is the right time to go to P66? I think some of my problems on my first attempts may have been from doing it too early [17:56:26] well Neil did it very early because he saw a field of bolders [17:56:41] I'm doing it rather late in P64, maybe 20 seconds left [17:56:47] not sure how AlexB_88 does it [17:57:04] oh okay, Neil did it early [17:57:14] oh yeah [17:57:16] I watched the video last night and it looked like he was at about 500ft or so [17:57:22] I think I may have been above 1000 [17:57:26] ran into fuel trouble almost [17:57:28] right [17:57:53] it's more personal technique [17:58:12] I trust the computer quite far, unless I don't really like where it sends me [17:59:53] 07/13/17 MAS Added simulation of HANDRUPT, as generated by [17:59:53] any of three traps, which monitor various bits [17:59:54] in channels 31 and 32. [18:00:07] this is what helped LPD with joystick [18:00:23] ah, was the problem that NASSP wasn't simulating the traps properly? [18:00:28] yeah [18:00:41] yeah that would do it :) [18:00:53] have you seen the P66 throttle oscillations yet? Or were you always distracted by not crashing? [18:01:04] oh no, the throttle oscillations are very distracting, haha [18:01:17] I wasn't expecting it to be that slow and obvious [18:01:44] it's so bad the altitude rate meter is not as helpful as it usually is [18:02:07] it freaked me out at first, because the throttle also jumps around with bad LR readings [18:02:25] haha [18:02:36] I think we might still be getting worse oscillations than the real thing [18:02:48] I would believe that, haha [18:02:57] because the real LM had a bit more lag with everything [18:03:05] DECA lag is a big one, we simulate that [18:03:10] I might actually be getting it even worse than you [18:03:14] DPS lag we don't simulate [18:03:17] hmm [18:03:31] that 0.075s thing that got compensated with 0.2s [18:03:35] and almost 0.3s [18:03:58] without the DECA lag P66 was unusable [18:04:06] hmmm [18:04:12] how big are the oscillations you get? [18:04:25] I should record a video so you can see what I'm getting [18:04:37] well it depends on the pitch rate [18:04:44] just holding attitude it's less [18:05:12] I really can't give a good number [18:05:18] have to try it a bit more [18:06:08] maybe 5-10% up and the same down [18:06:33] I'm not sure, but I think I might have made it slightly worse recently [18:06:37] hehe [18:07:01] when implementing the more realistic DPS thrust and ISP [18:07:21] before that I actually made the engine throttle to 92.5% only [18:07:42] well, there wasn't any point in my failed P66 attempts where I felt like the LM being out of control wasn't my fault [18:07:53] but now the uneroded thrust is 100%, equal to the thrust we had with 92.5% before [18:08:01] it always felt like I could save it if I sucked at flying LMs less :P [18:08:03] so auto throttle voltage scaling is slightly skewed [18:08:13] it's weird anyway [18:08:24] hmm [18:08:25] 0-12V, but 12V is beyond 100% throttle [18:08:55] I definitely have it all right from the LGC to DECA output [18:09:30] but how much thrust a specific voltage from the LGC (via the DECA) is, is not so trivial [18:09:49] I think the LGC software treats it as the maximum rated thrust [18:10:09] so with actually less thrust being present it doesn't overshoot the throttle setting the LGC wanted [18:10:28] which it does a little for us [18:10:32] and did before [18:10:53] at throttle down it goes like 100% -> 52% -> 55% [18:10:54] or so [18:11:09] right, I think I've seen that [18:11:33] brb [18:12:19] one more question for when you get back: I think I saw a reference somewhere to going back to AUTO in P66 nulling horizontal velocity. is this only a feature of later luminaries or does 99 do that too? because that sounds super nice [18:25:19] yeah, that is only auto P66 [18:25:26] Luminary 131 and later [18:25:41] boo [18:26:37] you can only downgrade on 099 [18:26:45] P65 -> P66 -> P67 [18:27:38] having failed a few landings in P66 now, P67 scares me :D [18:28:02] yeah it's not so easy [18:28:07] that is real helicoptering [18:30:24] Luminary069 is worse all around [18:30:36] hahaha how so? [18:30:43] there was a big update package to 099 accounting for the guidance period of 2 seconds, which they didn't do before [18:30:52] in P63 to P66 [18:31:34] so in all slightly more extreme cases, just shortly before switching to the next program is enough, it doesn't feel very stable [18:31:51] oh boy [18:32:03] I had a transition from P64 to P65, where everything seemed normal, but I had a bit of roll and it somehow ended up yaw me by about 10-15° [18:32:09] oh wow [18:32:09] then in P65 it was stable [18:32:21] yeah that's not good :D [18:32:49] I think I remember you saying at some point that 116 was the first actually good version of Luminary, haha [18:33:08] Luminary memos 62 and 63 [18:33:17] yeah they fixed all the radar bugs [18:34:31] oh right, I need to look up what the proper RADMODES value is from the virtualagc scenario [18:34:47] if you don't like the throttle oscillations there are even a few more Luminary versions to dislike, haha [18:34:55] hehehe [18:35:15] oh, I think I finally found which relay is used for the AGC liftoff discrete [18:35:20] earlier today [18:35:21] oh nice! [18:35:23] AS-501 Systems Handbook [18:35:31] oh of course [18:35:34] EDS seems fairly developed, so I tend to trust it [18:35:56] although there already are some signals I wanted to implement which are certainly not there on the manned missions [18:36:17] but I think it's the exact same relay as the LVDC liftoff signal [18:36:34] it says K4 in the Systems Handbook [18:36:38] that's the one for the IU [18:36:55] that handbook has about the best IU/CSM interface schematic I have seen so far [18:37:24] those older systems handbooks are great [18:37:51] yeah, the LM-1 one also had some gems [18:50:35] I think I will test a few landings and look for the throttle [18:50:56] and will also see if I can find a better number for the auto throttle scaling [18:52:23] no point in making the oscillations worse than they have to be [19:02:13] although, 12V auto throttle commands more than full throttle. So a smaller voltage change would command a larger thrust change than we currently do. [19:02:26] So maaaaaaybe making it better would make it even worse :D [19:06:08] making it more realistic* [19:20:16] hehehe [19:45:21] Evening [19:50:22] hey [20:05:27] night! [12:26:33] hey [12:31:02] hey Alex [12:35:05] I wrote down all the steps of the EDS test. At least I think I got it all. [12:35:20] So at some point I can try and implement that fully [12:39:08] but first I'll try to continue flying Apollo 8 and not get distracted [12:40:46] the test at T-1h55 you mean? [12:40:48] haha [12:42:43] yeah, that test [12:43:28] it needs a few more things wired in S-II and S-IVB, to simulate the LV engine lights being on or off [12:43:40] so more umbilicals [12:47:03] and a simulated liftoff signal would start event and mission timers [12:47:14] so they probably did not send the signal for the LEB timers [12:47:26] I don't think you can really reach those while in the seats [12:47:39] and they probably would need to be reset, at least the event timer [12:49:27] not quite sure [13:20:08] have you seen this yet? http://www.righto.com/2019/07/bitcoin-mining-on-apollo-guidance.html [13:25:26] back in a bit [13:28:43] interesting [13:51:30] and I thought running P37 too much on the real AGC would be too risky in case something breaks :D [13:52:04] little did I know that they were going to something like... this [13:54:20] yeah [13:55:32] but it's fun that it is possible [15:07:16] Ive been calculating a bunch of TEI's with carious missions just testing stuff [15:07:21] various* [15:08:57] So I guess up to Apollo 14, they just optimized DV with an INC limit of 40, then afterwards they removed that limit [15:09:11] I think so, yeah [15:09:31] but one interesting thing is the Apollo 15 TEI, optimizing it gives a 25 descending return [15:09:41] but they forced it to a 40 A [15:10:07] could that be something with the plane change maneuver? [15:10:14] that you aren't in the orbit that they were in [15:11:39] well one thing I did was check the DV's with the 40A return against the real pad [15:11:43] it is quite close [15:12:23] much closer then the 25 D return (optimized) [15:12:25] hmm, ok [15:12:39] is the 25D much better than the 40A? [15:12:44] DV wise [15:13:08] maybe 100 fps? not much more [15:13:43] 100 fps less for the 25D I mean [15:14:58] the 25D gives a very low DVY, but forcing it to 40A. gives it a DVY very close to the actual pad ~700 fps [15:15:25] so that leads me to believe my trajectory is quite similar to real [15:16:03] using 40A [15:16:12] yeah [15:16:20] I guess they calculated this to land at specific latitude and longitude [15:16:47] I wonder if that landing point was chosen to be the same for the whole launch window etc. [15:17:13] Apollo 15 SCOT says EI was 40A [15:17:39] maybe that makes 40A the best choice for the average launch in the launch window and both TLI opportunities [15:18:44] well if it is exactly 40A, then it was probably calculated to a specific longitude [15:20:49] "to [15:20:49] the end-of-mission target line (158°W) at 295 hours g.e.t. with a 40° [15:20:50] ascending inclination. " [15:23:03] I would bet on some recovery constraints [15:23:16] maybe in some cases the A and D solutions would be close to being the same [15:23:25] leading to very different splashdown latitudes [15:23:51] they wanted to know where they are going to land early [15:24:26] right [15:25:35] I think the earlier TEI's on 15 (aborts) were not strictly 40A though, based on caprisons from the real pads [15:26:17] TEI-62 for example, I get very close to the same as the real pad but optimizing and getting an INC of I think 25-30 D [15:27:24] by* [15:28:25] yeah, but they differentiated between a nominal and a contingency return [15:28:36] which don'T have the same splashdown longitude [15:28:50] right [15:29:11] and if they had planned to use 40A for nominal returns, then that wouldn't apply to the abort PADs [15:31:04] still only relatively weak explanations though [15:36:45] yeah [15:37:03] oh I had an unrelated question for you [15:38:44] sure [15:39:08] Prior to Apollo 14, they planned a constant translunar flight time. In the Apollo 12 SCOT for example it says a transluanr flight time of 80.6 hours. Is this figure from TLI cutoff to LOI ignition? What are the start & end points? [15:40:31] The reason I ask is if for Apollo 12 you wanted to simulate a launch delay, I think you would have to recalculate the lunar PC time of arrival to keep the 80.6 hours TLC time [15:40:32] I don't know exactly, but maybe TLI cutoff to flyby? [15:40:54] yeah, PC time [15:41:17] where did you see 80.6h? [15:41:42] at the beginning of the Apollo 12 SCOT page 22 (1-6) [15:43:15] right [15:47:00] not sure really [15:47:59] looking at the SCOT I think its from TLI cutoff [15:48:05] to PC GET [15:48:49] I wonder if would just move the whole timeline [15:48:55] for a late launch that is simple [15:49:00] 2nd TLI not so much [15:59:19] "The duration of the translunar coast phase is 80 hours 36 minutes." [15:59:24] coast [15:59:34] so maybe it is TLI cutoff to LOI ignition [16:14:19] we do have data for such a case, Apollo 11 July 21st launch [16:15:28] ah right, wasnt that a hybrid mission? [16:15:43] yep [16:16:04] I forgot about that one [16:16:18] Ill have to derive some RTCC constants for that one [16:17:59] maybe we can add an already-open RTCC MFD to that scenario with the correct values [16:18:04] I still have a launch scenario for July 18 that is in pretty good shape and one for 21st that needs a bit more work [16:18:56] ah, I had already commited the July 18 one a while ago [16:20:07] well the Delta T from TLI definitely not 0 for Apollo 11 July 21 [16:20:15] delta T to LOI, or PC [16:21:43] maybe the answer is simply [16:21:47] it's DV optimized [16:22:14] what is really constant for those is the hybrid trajectory flyby altitude [16:28:13] REAL TIME COMPUTING REQUIREMENTS FOR APOLLO 12 [16:28:17] I wonder what this is [16:28:29] JSC History Collection [16:28:37] APOLLO 12 LUNAR TRAJECTORY NOTES [16:28:39] also a good one [16:33:24] but yeah, maybe it simply is optimizing the DV with the pericynthion time [16:33:35] the real RTCC would be able to do this automatically [16:33:52] and there wasn't a reissue of the non-free return targeting RTCC requirements until Apollo 13 [16:46:40] yeah [16:47:24] so that is what I think from the Apollo 11 data. Only thing constant is the flyby altitude the LVDC is targeting [16:47:48] https://www.youtube.com/watch?v=I7VLIjsKxkU [16:48:01] Marc is running out of days until the anniversary, haha [16:48:24] but after this part should come where Mike is running my core files. I hope :D [16:50:21] nice [16:51:05] So I am manually optimizing DV for arrival GET, the most optimum gets me there 20 minutes early from the flight plan [16:51:09] well he did do it one time, but ran into the "IMU not on" alarm [16:51:11] Apollo 12 [16:51:18] hmm [16:51:18] ah right [16:51:29] for a nominal launch and TLI? [16:51:34] yeah [16:51:39] damn [16:52:29] maybe due to the IU SV issues the real one had (and the presettings we derived) [16:52:53] pretty sure I derived it from the preflight numbers for all missions except Apollo 10 [16:53:05] ah right [16:53:42] so I don't know [16:54:11] if it was still working like the earlier non-free return targeting they could put constraints on the pericynthion time [16:54:32] that was used to keep it in the window for a DPS PC+2 [16:54:58] I mean, we dont have presettings that support late launches for Apollo 12/13 anyway [16:55:24] yeah [16:55:38] well for a Apollo 12 September 1969 launch we have :D [16:55:40] the current RTCC constants preloaded in Apollo 12 get you to the moon within a minutes of the SCOT I think [16:55:59] a minute* [16:56:08] for nominal launch [16:56:56] nice [16:57:14] well I will definitely look into it with all detail I can once I work on the Apollo 12 MCC [16:58:05] there is also one gigantic polynomial that is used to figure out the nominal translunar flight time [16:58:13] mainly as the initial guess though [16:58:18] but I never implemented that [16:58:25] I wonder if that gives some interesting results [17:01:39] I'll experiment with it in MATLAB [17:02:36] prayers to the god of typos that the numbers in the RTCC Requirements document for that are all good [17:03:09] morning! [17:03:48] hey [17:04:06] fixed my crosspointer problem [17:04:10] yay [17:04:12] it really helps in P66, heh [17:04:17] sure does [17:04:22] especially in the low setting [17:04:25] yep [17:04:34] that plus altitude rate on the tapemeter [17:04:37] although even then it's a little less sensitive than I expected [17:04:50] sensitive? [17:05:46] like in final descent in P66, I can still see movement out the window when it looks like my crosspointer is right on 0,0 [17:05:53] ah, right [17:06:33] you are supposed to look out of the window then anyway :D [17:06:39] hehehe [17:06:56] full scale high is 20 ft/s in the LO MULT setting [17:08:15] LGC outputs it at the high scaling [17:08:31] low setting just makes it 10x finer [17:08:54] I'm sure I properly tested it way back [17:09:01] oh yeah I'm sure you have it right [17:09:06] but you saying that make me want to check [17:09:09] hahaha [17:11:02] so I just need to get better at controlling things [17:11:13] one other question I had, and I thiiiiink the answer is no, but I haven't tried it [17:11:55] is there any way for me to set up a scenario that starts right at the P63/P64 changeover so I can practice the approach and landing phases a bunch without having to sit around through P63 between each try? [17:12:22] yes [17:12:28] oh great [17:12:30] it's not ideal [17:12:32] hahaha [17:12:38] but it should work [17:12:45] accelerometers don't like it that much [17:12:59] being already used at scenario start [17:13:12] but I think the bigger problems with that might be on your side, no? [17:13:38] so just go ahead, fly a landing, and save at the right time [17:13:43] lands in the quicksaves folder [17:17:10] I think it shoooouuulllld work fine on my side [17:17:34] during scenario loading I set all of the erasable and output channels to the expected values [17:20:14] you can try it then [17:20:27] I can give you a scenario for that, but you can very easily make it yourself [17:20:39] I'll focus on adding more scenarios for other missions [17:22:08] yeah, I'll just have to fly a landing with virtualagc [17:22:33] ah right [17:22:42] didn't think of that [17:22:56] easy enough though, I just have to remove the line from my scenario file :) [17:23:11] btw, are you handling the saved input channel data all correctly now? [17:23:20] what do you mean? [17:23:29] well, in the scenario, it saves input channel data [17:23:44] not all of which is re-done on every timestep [17:24:00] I pass 30-33 into the monitor [17:24:02] so maybe when you start in late P63 the AGC will think some switch setting is wrong [17:24:05] I think I might ignore the others [17:24:54] are you passing the 30-33 data from SetInputChannel(Bit) only or also the ones saved in the scenario? [17:25:01] both [17:25:05] ah [17:25:08] that was the question [17:25:22] I load them from the scenario at start, and then as they change via SetInputChannel(Bit) I update them [17:25:30] yeah, that's ideal [17:25:40] you learned from the 210 alarm I see :D [17:25:43] hehehe [17:26:09] I need to try some other missions now that everything basically works [17:26:13] already a new AGC restoration video today, but still working on fixing things [17:26:18] yep [17:26:21] that damn current switch module [17:26:26] indeed [17:26:45] but once it gets fixed I hope to see some more P63 or P37 action! [17:27:04] and I will have to add some more mission scenarios [17:27:05] oh definitely [17:27:10] haha [17:27:11] next up 15 I guess [17:27:22] yeah, I really want to do both 15 and Zerlina [17:27:36] should be done quite quickly [17:27:49] I just try to make sure the auto landing area without any LPD is ok [17:27:50] no rush :) [17:28:06] that was not so easy with the north rim of Tycho crater :D [17:28:38] of course now auto landings aren't a hard requirement anymore [17:28:42] yep [17:29:07] you'll enjoy the scenarios without throttle oscillations [17:29:24] haha yeah [17:29:32] I'll be curious to see if there still are some with the USB lag [17:29:43] for us it's basically gone completely [17:30:11] even though we don't simulate all lags that exist in the real spacecraft [17:33:16] right [17:33:24] so just to make sure I'm not missing anything... input channels, throttle, tape meters, FDAI needles, cross pointer, hand controller, ROD switches [17:33:59] this morning I was playing around with injecting TLOSS :) [17:34:47] missing nothing for normal operation of the LM [17:35:11] PGNS to AGS downlink? :D [17:35:15] haha right [17:35:24] maybe, now that I can inject downrupts [17:35:32] I'll have to play with that [17:36:38] AlexB_88, 102.4 x 102.6 insertion with Apollo 8, I like that very simple LVDC fix :D [17:37:45] nice [17:43:58] one of these days someone has to scan the rest of the Apollo 8 LVDC presettings [17:44:31] Ron sent me photos for the December 21st launch, but there were presettings for all the other days in the December and I believe also January launch window [17:46:25] I want to visit that archive at some point [17:47:23] yeah, they had a few nice things [17:47:37] have to look through those photos again [17:49:58] even an updated EDS manual [17:50:11] not sure if that is a 1966 or 1968 though [17:50:17] Ron shaking too much during the photo :D [17:50:27] hehehe [17:56:37] CSM Functional Integrated System Schematics [17:59:22] we could probably get those from NARA [17:59:28] are any drawing numbers visible? [18:08:35] doesn't look like it [18:34:55] PDI-0 TIG is perigee correct? [18:34:58] I think it is [18:35:28] Orbit Digitals display makes that easy :D [19:04:35] AlexB_88, I think so, basically the same point where a PDI would be [19:04:43] whoa whoa whoa [19:04:46] whoooooooooooaaaaaaaaaaaa [19:05:21] https://virtualagc.github.io/virtualagc/changes.html [19:06:43] aaaaaaaaaaaaaah [19:07:08] whaaa [19:08:08] atan2 implementation agrees with the EDD [19:09:51] anonymous informant, of course [19:09:56] yeah [19:11:58] it's a beginning [19:12:22] I really hope Ron is able to talk this informant into giving the rest [19:12:24] man that would be cool [19:13:06] more motivation to continue throwing things out of the LVDC++ timestep that doesn't belong there [19:14:27] and I'm sure there is more [19:14:40] if not LVDC source code, maybe more EDDs and all that good stuff [19:17:05] LVOTs [19:19:09] no date or anything in the photos :( [19:19:14] or version number or anything [19:19:20] yeah [19:19:32] kind of surprising, AEA and AGC listings both had that [19:19:37] on every page [19:24:17] I'm not quite sure what do to with this news :D [19:28:57] haha me neither [19:29:11] I think the answer is probably nothing [19:29:14] but man [19:29:18] it's just so unexpected [19:34:24] I mean, we are nearing the anniversary [19:34:47] some things have already come to light thanks to that [20:07:39] right now I am writing myself a guide on how to build all the various rendezvous maneuvers (PDI-o, No-PDI+12, etc) and the differences between missions [20:09:18] the kind of document I would like to find from back in the day [20:09:29] Well, we did find something like this for Apollo 9 rendezvous [20:10:04] but that sounds like something quite useful and worth sharing on the forum when it is done [20:10:15] next to me writing an update RTCC MFD manual... [20:13:10] yeah [20:14:11] its a very rough copy written by hand right now, but I will definitely clean it up and make it into a document that I can share eventually [20:31:30] night! [05:37:33] heheehe [05:38:00] TLOSS injection is working [06:21:22] wow [06:21:31] the AGC behaves surprisingly well with high TLOSS [06:21:49] just flew a perfectly good landing without a single display update in P64, and many restarts [14:22:57] hey [14:39:18] hey Niklas [14:49:56] what's up? [14:52:02] just continuing my RTCC MFD guide, up to TEC [14:52:59] Ive outlined the procedures for calculating pretty much every nominal and abort maneuver pads [14:53:00] nice [14:53:11] I'm making some more scenarios for Mike [14:53:18] and the differences between the missions [14:53:19] nice [14:53:20] right [14:53:41] the LVDC code owner has no EDDs it seems [14:54:00] ah bummer [14:54:02] "owner", he doesn't admit that it is his [14:55:51] I had a question about the TPI time for the coelliptical rendezvous's, should there be an option to select other then orbital midnight TPI time, because I think its hardcoded for those in the RTCC MFD [14:56:44] probably [14:56:57] I haven't looked at that part for so long [14:57:56] on the Coelliptic page? [14:58:22] I think most of the co-elliptical rendezvous were indeed calculated with orbital midnight TPI time, but I think that in some cases they used the SR minus 16m: Apollo 14 to 17 for the T3 liftoff and all liftoff time updates on the moon, and the co-elliptical ascent pad read along with the direct one [15:00:24] yeah on the liftoff page, coelliptic option [15:00:34] yeah, I guess the lunar liftoff page should get an alternative TPI time option [15:01:13] for the direct option, its already fine, because you can play with the DT to get the correct TPI time [15:01:35] right [15:02:01] and the TPI time being calculated with the DKI "TPI time only" option [15:03:05] as of February 1969 the only options for TPI were: time input, longitude input [15:03:14] but I have been looking through the docs and cannot find a definetive answer on this, maybe all coelliptical ascents were indeed targeted with TPI at orbital midnight [15:03:18] with the right lighting being calculated externally [15:04:40] some of the programs involving rendezvous could definitely calculate lighting internally though [15:05:13] just to view this from a "what capabilities did they actually have" point [15:06:07] right [15:07:59] I don't even know if they really ever used orbital midnight in any calculations [15:08:16] or rather a specific time from sunrise [15:08:21] right [15:08:24] -23 mins [15:08:45] yep [15:10:02] for the nominal ascents, Up to Apollo 13 it was -23m, Apollo 14: -18.5m, Apollo 15 to 17, -16m [15:10:15] Apollo 7 rendezvous techniques is very clear about it being midnight of darkness [15:12:31] Apollo 9 used 25m30s before sunrise for the calculation [15:13:10] by looking at the sunrise/sunset table [15:14:39] https://archive.org/details/NARASWSelectedApolloBoxes/page/n725 [15:14:43] wouldn't this be nice to have [15:25:22] yeah [15:26:52] so the RTCC RTE constraints have the range override set to 1190 NM RTGO for re-entry on Apollo 15, but the entry pad shows 1087 (which is correct from real pad) [15:27:08] oh its 1190 from RRT? [15:27:21] and I guess thats not the same as the EMS value [15:27:23] 1190NM from EI to splashdown [15:27:25] yeah [15:27:30] right, that makes sense [15:27:34] EMS range starts at 0.05G [15:27:41] well then its perfect [15:28:10] great! [15:28:43] I'm flying Apollo 5 to create a few scenarios, I guess I should add the LM RCS being usable before SLA/LM sep [15:29:05] same as I did with the CSM. Sunburst wants to do ullage before the sep starts [15:31:13] hmm [15:31:53] does the RTCC MFD have the updated HOR CK pitch for the entry pad, it seems it still uses the old value ~299 [15:31:56] oh no [15:31:59] CTD at sep [15:33:48] uh oh [15:34:14] seems like something we did with the LM broke it [15:34:20] DX9 Client crash it says [15:34:27] to be fair, Apollo 5 was always buggy [15:34:36] maybe I had to save and load [15:34:50] even before, to make it without crash [15:34:54] not sure [15:36:20] RTCC MFD should use the same calculation as the MCC [15:36:26] and it seems to use the 31.7° [15:37:48] on later missions they didn't have the line at 31.7° though [15:38:39] but 299° would definitely be wrong [15:39:50] do you have the Entry REFSMMAT? [15:40:45] yeah [15:41:00] EntryPADHorChkPit = PI2 - (horang + coastang + 31.7*RAD) + IGA; [15:41:06] looks like 31.7° to me, haha [15:41:14] but there could still be something wrong of course [15:42:47] ah this was a pre-TEI calculation with the MPT activated [15:42:50] maybe thats why [15:43:09] when I use an actual TEC scenario on Apollo 15, it shows the correct 268 P [15:43:58] the pre-TEI Entry REFSMMAT? [15:44:10] maybe the Entry REFSMMAT calculated wrong if you did that [15:44:31] right [15:45:29] ah maybe the lunar entry REFSMMAT option is not compatible with MPT [15:45:51] REFSMMAT calculation is compatible in general, but I never tried to calculate the entry one from before TEI [15:46:17] well, one thing though, the entry attitude was correct 000,152,000 [15:46:18] should be though [15:46:22] yeah [15:46:32] so I think the REFSMMAT was good, even calculated pre-TEI [15:47:38] no idea then [15:48:16] not very important, who else would try and calculate an entry REFSMMAT before TEI but me anyway :D [15:49:00] well, people writing a SCOT :D [15:49:12] yeah [15:49:17] one thing I have to figure out (remember) now is what exactly they targeted the shape burn [15:49:42] I think it was something in the GPM processor [15:49:59] one of the Apollo 15 docs had info on that [15:51:21] "so that, when the subsatellite is jettisoned as the ascending node on rev 73, it will have a lunar orbit lifetime of one year" [15:51:36] thats Apollo 16 SCOT [15:51:52] but I guess Ill need to find that Apollo 15 doc you speak of [15:52:16] ftp://ftp.sciops.esa.int/pub/ekuulker/Apollo15_Navigation_Results.pdf [15:52:30] PDF pages 229 and 230 [15:54:28] ah thanks [16:00:23] so targeted longitude of ascending node 42 DEG. with 75x55 NM orbit [16:01:49] is that either an apsides shift or node shift +Apo/Peri change? [16:03:55] I rather think the latter [16:06:29] there is so much from the Apollo 11 audio I still want to listen to. I wonder if the FIDO loop ever has anything on the plane change maneuver [16:06:40] they didn't have to do one, but they surely calculated one [16:08:17] and I'm sure the audio for all the other mission also has survived [16:08:31] just digitizing them for all the missions is a giant effort [16:15:05] well saving/loading already fixed the SLA animation state, so hopefully I can now continue Apollo 5 [16:15:06] LONG MAN, is that longitude of ascending node? [16:15:17] in the RTCC MFD? [16:15:30] yeah, GPM Orbital parameters section [16:16:03] I think that is longitude, for a manually selected time [16:16:25] uhh [16:16:26] no [16:17:21] longitude at the maneuver TIG [16:18:15] ah yes, Apollo 5 works very well [16:18:17] not broken at all [16:18:28] literally perfect [16:18:28] https://i.imgur.com/ROs13c1.jpg [16:19:42] it gets better [16:19:56] I thought saving/loading might fix it [16:20:07] only the descent stage is loaded [16:24:46] haha [16:25:28] cant say Im not partially to blame, maybe something from all the changes I did to the LM [16:26:18] yeah, and I didn't properly accomodate them in the LEMSaturn class [16:26:34] I think it is stable now though [16:26:37] with some scenario fixing [16:26:46] good enough to give to Mike [16:31:15] I guess I'll make three scenarios, simulated DOI, PDI/abort and ascent [16:37:57] I figured out an alternate way to do the plane change maneuver [16:38:17] requires 3 RTCC MFDS :-O [16:38:50] oh boy [16:39:11] 1 showing the GPM in plane change mode, 1 showing the PDI pad, and 1 showing the MPT [16:39:34] I can then play with the DW, increasing it until the CR on the PDI pad goes to 0 [16:39:56] speaking of plane change, the document I gave you also has something on that [16:40:01] PDF page 205 [16:40:42] I never really put this method in practice. Neither does it really give a complete picture of the calculation methods used for e.g. TIG [16:41:14] yeah [16:41:55] but it's still interesting [16:45:20] sounds like it was something very much dependent on actual conditions, calculated in real-time [16:47:01] got a restart and program alarm [16:47:17] seems like Apollo 5 is properly broken right now :( [16:48:00] it's funny, it is stuck in a loop trying to close one of the thrust pair switches [16:48:15] thruster* [16:51:15] morning! [16:51:17] AlexB_88, pushed a few updates just now [16:51:32] including the 40A/40D input method for the RTE [16:51:34] hey Mike [16:51:49] what's up? [16:52:02] good news, added an Apollo 15 scenario for you. Bad news, Apollo 5 is currently broken in multiple ways [16:52:24] it threw me a program alarm and restart a while before DPS-1 maneuver [16:52:30] uh oh [16:52:37] so I think I can't give you a scenario for that right now [16:52:51] okay, no worries :) [16:53:29] I managed to make a scenario right at the start of P64 last night and flew a bunch of landings [16:53:51] https://i.imgur.com/ROs13c1.jpg [16:53:59] nice [16:54:02] definitely getting a better feel for how to use the LPD, and I'm getting better at P66 flight, although I still sometimes try to slow down too quickly and end up going backwards [16:54:11] hahahaha what happened there? [16:54:19] indy91, great [16:54:29] hey Mike [16:54:32] meshes and animations being messed up from work on the LM, but the LEMSaturn class didn't get the memo [16:54:35] hey [16:54:38] hehehe [16:55:01] not sure why Sunburst had an issue though, all seemed well until it wasn't [16:55:14] :( [16:55:15] it got stuck in a loop commanding something to the programer [16:55:18] weird [16:55:20] or maybe the programer didn't properly reset [16:55:32] tried to close one of the RCS thruster pair switches [16:55:47] maybe it detected an RCS failure or so and couldn't handle it [16:56:03] I cycled those switches to clear red flags [16:56:07] maybe that was bad [16:56:27] so I have a bunch of things to fix [16:56:27] hmmm, could be [16:58:10] so, I had some questions about TLOSS [16:58:23] and what you saw when we were messing around with trying to cause 1202s a while back [16:58:40] right [16:58:54] I added configurable TLOSS injection to the monitor last night, and was playing around with numbers [16:58:57] not many DSKY updates in the more extreme cases [16:59:30] and more realistic cases, too. Gone for up to 10 seconds [16:59:36] hmm [17:00:03] so if I adjust the number high enough to get alarms with 16 68 up in P63 [17:00:28] then my P64 is completely broken -- no DSKY updates at all, and maybe a dozen alarms during approach [17:01:01] if I adjust it down such that P64 even works a little bit, then I'm not at all close to getting alarms in P63 [17:01:11] well you wouldn't get alarms in early P63 [17:01:18] only with LR data being good and 16 68 up [17:01:27] I mean, end of P63, with LR incorporated and 16 68 up [17:01:43] it was a bit worse for me in P64 [17:01:44] expecting that they would show up around the 6 minute mark [17:01:46] but not that much [17:01:49] hmm [17:02:08] very weird [17:05:13] I'm going to change my code to behave exactly like a misbehaving CDU tonight [17:13:09] AlexB_88, yeah, LEMSaturn class doesn't like your LM mesh work [17:25:23] bummer [17:25:42] anything in particular? [17:27:33] well meshes [17:27:34] ClearMeshes(); [17:27:35] SetMeshes(); [17:27:40] doing this might already fix it [17:27:42] have to test [17:28:47] yep, looks right visually again now [17:30:10] so coasting up to the point where the issue with the LGC happened and hoping it doesn't happen again. I did some scenario editing after all and maybe some more memory unsafe things happened [17:32:53] if it happens again I'll try to get the alarm code and data this time [17:39:12] so CSM-104 [17:39:20] the handbook has panel schematics [17:39:28] high gain antenna limit light is there [17:39:38] but optics panel is as we have it now [17:52:05] clearmeshes() does bad things to animations in the [17:52:10] LM [17:56:08] yeah, but I don't let them being defined until later [17:56:12] the full sequence there is [17:56:16] ClearMeshes(); [17:56:16] SetMeshes(); [17:56:17] SetLmVesselDockStage(); [17:56:18] DefineAnimations(); [17:56:51] looks normal now, in any case [17:56:59] https://i.imgur.com/EN32bNV.jpg [17:59:20] ah ok [17:59:51] normal? it has no legs :D [18:00:17] forgot them on the ground [18:02:37] thewonderidiot, did I already gave you the less on pre PDI scenarios for later missions? With the master arm? [18:02:49] lesson* [18:03:10] nope! [18:03:19] so on later missions the CSM does the DOI [18:03:29] meaning that the descent burn is the first burn for the DPS [18:03:38] oh fun [18:03:39] on the first burn a set of explosive valves gets opened [18:03:55] on previous missions that happened on DOI [18:04:08] so at TIG-1 second you have to set Master Arm to On [18:04:15] and that plus the DPS actually running does it [18:04:35] it's in the checklist, just don't assume that you learned the checklist for 11 and it applies for all missions :D [18:04:51] hahahaha [18:05:04] fair enough! [18:05:13] not really sure how much this applies to us right now, DPS pressurization section isn't that advanced yet. [18:05:15] I will make sure to review the checklists for the scenarios, haha [18:05:19] But potentially it could give you low thrust [18:05:35] yeah, LM Timeline Book is available for most missions [18:06:04] I have a feeling that we will finally get the relevant pages for this for Apollo 12 very soon [18:06:05] I might try some other scenarios tonight now that I'm feeling comfortable with 11 [18:06:25] the copy that is available is missing some pages for Apollo 12 [18:06:32] but I know someone :) [18:11:26] ok, I think I am past the point where I got the alarm with Sunburst on the last attempt [18:12:07] maybe the problem was cycling the thruster pair switches [18:12:17] that sets an input bit to the AGC [18:12:21] failed thrusters [18:12:25] maybe it reacted badly to that [18:12:35] even if the condition should have been there for just a second [18:15:57] DPS-1 scenario should work on the AGC [18:16:16] DPS-2 is the one where it does a DAP test that needs downlink [18:16:22] although I think that can be disabled... [18:16:32] I can inject downrupts :) [18:17:15] well, maybe you can soon test it on Sunburst [18:17:24] seems to all work now again [18:21:40] good burn [18:22:44] the pre-DPS-1 scenario is definitely one that would make Don happy :) [18:23:34] Sunburst always puts V34 on the DSKY when in a critical phase [18:23:56] maybe so that you can quickly uplink and ENTR to stop it from doing what it is currently doing? [18:23:59] an* [18:26:28] Hey [18:26:35] hey Thymo [18:27:22] I've been playing around with the LEM today, trying to figure the systems out. Managed to do a partial power up. [18:29:23] nice [18:30:41] with the LM it is really starting all the systems up from nothing [18:33:40] Yeah [18:33:51] I just can't figure out how to open the tunnel hatch in the CM [18:34:08] Actually nevermind. [18:34:13] I just found it [18:34:32] Does it not open under certain circumstances? [18:34:56] only opens if the delta pressure is below 0.08 psi [18:35:13] Ah. That's probably what prevented me from opening it earlier [18:36:06] yeah, can be quite tricky during LM pressurization [18:36:56] Same goes for the forward hatch? [18:40:09] yep [18:40:16] Cool [18:45:29] perfect DPS-2/FITH/APS-1 test [18:45:34] always fun to watch [18:47:08] well the orbit is not as in the SCOT, but we got that before [18:47:14] might lead to reentering after APS-2 [18:48:00] indy91, Apollo 15 flight plan block data schedule says "All TEI's are constrained to 40 INC" [18:48:07] I missed that one [18:48:49] I guess thats just saying they shall not exceed 40 INC, but I think that nominal TEI (74 and 75) were forced to 40A [18:49:54] but I wonder if we should then add the 40 DEG max return inc limitation to the RTE constraints [18:49:56] hmm [18:49:59] for Apollo 15 [18:51:29] I guess so, yes [18:53:06] doesn't say that for 16 [18:53:10] nope [18:53:12] so maybe on 15 they still used the constraint [18:53:21] even though the SCOT deleted it [18:53:31] 16, 17 TEIs both had higher then 40 inc [18:53:37] yeah [18:54:29] I find the SCOT and the flightplan for 15 differ a bit [18:54:50] like there was a shape burn on 15, but the SCOT doesnt mention it [18:55:02] old revision maybe [18:56:41] April 16 [18:56:47] not that far away from launch [18:56:50] ah its because of the subsatellite launch [18:57:01] in the SCOT they have it at 104 hours or so [18:57:23] but on the flight plan, its after the shape burn, right before TEI [18:57:57] flight plan is June 21st [18:58:34] so yeah I guess it had a few months of changes [18:59:46] yeah [19:02:41] also, I want to figure out the PTC REFSMMAT times by reverse engineering the ones in the SCOT [19:03:48] that would be useful [19:09:01] oh, did I read that we may get the missing pages of the Apollo 12 LM timeline book? [19:12:21] correct [19:12:24] I know someone with a copy [19:15:01] LM-1 did deorbit itself [19:15:08] I think this is what Mike also got when he tried it [19:15:46] there is one padload change that didn't make it into the launch scenario I believe, because I did not properly keep track of it [19:16:06] I'll have to look [19:26:42] yep, I got a deorbit [19:37:06] Sunburst 120 padload worksheet, we haven't seen each other in a while [19:39:57] yeah, I think the scenario simply still has the March 1967 padload document numbers [19:40:02] and not the updated SCOT numbers [19:40:12] I updated my in-flight scenario back then, but not the launch one [19:41:24] the T-1h scenario has the updated numbers [19:41:34] so might simply be a copy&paste case [19:44:51] would it be possible to get a separate variable for the PTC REFSMMAT time? [19:45:12] sure [19:45:13] then we could load it in the mission constants [19:45:23] easily done [19:45:43] I can take care of figuring out each of the times [19:46:46] sure [19:49:32] thewonderidiot, mixing APS-2 padload parameters from the SCOT and from the March 1967 padload document, very unhealthy! [19:49:45] pretty sure that is the reason for the deorbiting [19:50:22] target plane vector was the issue, which is basically simulating the orbit of the CSM for the P12 calculations [19:50:37] let's see if that helps... [19:56:54] ah! yes that sounds like a problem [19:59:29] probably spent more effort on achieving the target plane than the target orbit (apogee and perigee) [19:59:37] yep [19:59:39] that was it [19:59:48] orbit quite similar to the SCOT now [19:59:53] hmm [19:59:56] or not? [19:59:58] program alarm [20:00:35] maybe propellant depletion too early [20:00:39] or maybe this is normal [20:01:14] V05 N31 is 2013, 16003, 0 [20:03:28] hmmm [20:03:39] the orbit is really quite normal [20:03:43] maybe this is expected [20:04:17] "This burn is specifically targeted so that the APS fuel available [20:04:17] for impulse will be depleted prior to the time of guidance commanded [20:04:18] shutdown, some 60 s'econds away." [20:04:50] that alarm is from FORGETIT [20:04:50] in the previous case I didn't have a program alarm, but I think it is ok to have one [20:05:06] 315 alarm? [20:06:07] how do I check :D [20:06:09] which noun [20:06:17] it doesn'T let me check N09 [20:06:22] # FORGETIT IS ENTERED FROM: [20:06:26] # 4) ENGINE FAILURE, ETC. [20:06:32] this is probably the cause though [20:06:45] N50? [20:07:22] yeah, noun 50 [20:07:55] 1405 and 315 [20:08:16] DV alarm - engine on but no thrust [20:08:34] APS propellant was burned to depletion as planned, so that will do it [20:08:37] followed by forgetit alarm [20:08:39] so yeah [20:08:43] perfectly expected :) [20:08:44] sounds normal [20:08:45] yay [20:08:55] T-60s scenario finally fixed [20:08:59] nice! [20:09:14] and I can upload 3 Sunburst scenarios, before each major test [20:09:56] a bunch of RCS tests after this, but they all require MCC uplinks [20:10:11] I'll delete the MCC in the demo scenarios [20:10:52] you will probably not get to show this to Don or anyone, but juuuuust in case :) [20:11:19] hehehehe [20:11:26] I will definitely be ready to show him if he's interested [20:12:19] yeah [13:16:38] Afternoon [13:17:55] hey [13:21:33] Working on the Apollo 8 launch while packing my bags. Leaving for Italy tomorrow. :) [13:22:36] ah, nice [14:11:55] NASSP crashed. [14:12:15] I tried opening that test checklist in the mfd and the whole sim shutdown [14:24:33] which test checklist? [14:24:49] it will crash if it e.g. tries to access a switch that doesn't exist [14:26:08] On the Apollo 8 launch mission there is a Testing group way at the bottom. In there is a checklist called 'Tests'. [14:26:22] As soon as you go into that checklist the sim crashes without any messages. [14:26:33] It probably slipped in from some testing branch. [14:27:50] yeah, that doesn't even exist [14:27:59] there exist a checklist group called Test [14:28:21] but there is no "Tests", so it will crash, because it doesn't exist [14:28:26] both things should be deleted [14:28:49] Also, does time compression get disabled before launch? [14:29:02] Because I'm unable to accelerate on the pad. [14:29:56] it only stops you from doing excessive time acceleration [14:30:25] beyond 100 [14:30:30] It drops me even at 10 [14:30:38] that's weird [14:30:50] 2 even [14:30:52] I just flew Apollo 8 to post-TLI myself two days ago [14:30:56] and it worked for me [14:31:11] My limit is set to 0. That's supposed to be unlimited. The issue might be there. [14:31:33] mine is 0 as well [14:31:42] Weird [14:32:03] You used the MCC scenario? [14:32:07] Yep [14:32:55] works fine for me [14:33:07] Odd [14:33:15] Must be something on my end then. [14:34:59] can you open and close that scenario and then look at Current Scenario? [14:35:08] and check a specific line [14:35:16] STAGE [14:35:35] 11 [14:35:48] oh no [14:35:52] that's real bad [14:35:58] What happened? [14:36:04] that is the state it should have after liftoff [14:36:06] never before [14:36:26] that will do it [14:36:27] That's what I was gonna ask next. When I loaded my save MCC came up with LIFTOFF! [14:36:46] there is code that tries to limit your time acceleration to 1x before T+50s [14:36:50] but only after liftoff of course [14:36:53] so that is triggered [14:36:54] MissionState is 4 too [14:37:18] the launch state is currently set in the IU [14:37:23] whenever the IU umbilical drops out [14:37:40] if it never is able to connect it then that will happen immediately [14:37:54] I had that a few times when I was working on this umbilical stuff [14:38:15] but I don't see how that is possible [14:38:24] it should definitely be connected [14:38:32] did you delete the mobile launcher from the scenario? :D [14:39:10] It definitely seems to be there [14:39:33] whenever that happened to me it was always a clear bug [14:39:44] I have merged your PR, so I should be on the same state [14:40:08] and you used the T-4h scenario, right? [14:40:22] same one as I used [14:40:38] Yeah, with MCC. Currently at T-2:45:00 [14:40:55] I did stop in between and resumed from a save though. But that shouldn't matter. [14:41:03] yeah [14:41:05] but I will test that [14:41:09] maybe there is a bug with that [14:41:20] I usually do 10x and proceed from T-4h to launch without the need to load [14:41:27] and auto checklist [14:42:15] yep [14:42:16] that's the bug [14:42:21] I loaded the T-4h scenario [14:42:23] and closed it [14:42:26] opened Current Scenario [14:42:31] and I have the same issue as you [14:42:32] dammit [14:43:50] you won't be able to continue with that [14:43:59] when it is fixed you need to start again, sorry [14:44:46] No big deal [14:44:57] I'm sure it's caused by me changing the animations of the ML a bit [14:45:09] it uses the Vessel API functions to load and save [14:45:25] I should never trust the Vessel API :D [14:50:20] Actually, we're not on entirely the same codebase. [14:50:34] I wired the PCM in mine. That won't affect any of this. [14:50:49] I'll try to get it merged before I head off for two weeks. [14:53:22] I'm pretty sure it is a VesselAPI bug [14:53:35] if you set an animation to closing when it is already closed [14:53:43] have to properly debug that though [15:21:10] nah, it's mostly my fault [15:21:26] there is an animation state called closing, and one called closed [15:21:37] I set it to closing every timestep during prelaunch [15:21:52] so that got saved in the scenario, even if the animation tried to set it to closed [15:29:04] and then when it loaded from the scenario, it only connected the umbilicals if the swing arm animation was closed [15:29:05] not closing [15:35:13] fix is pushed [15:39:22] that's what I get for messing with something that was working fine, just to make it "better" [17:01:36] morning! [17:01:38] hey [17:01:44] what's up? [17:01:58] fixed a bad bug in prelaunch [17:02:08] I pushed my updates, including the ones for Apollo 5 [17:02:20] and the Google Drive folder with AGC scenarios got a bit bigger [17:02:44] if you want to try Apollo 5 and want to see more than the descent stage, then you need the update :D [17:03:01] nice :D [17:03:07] also just added 13 [17:03:09] will merge your stuff in tonight [17:03:13] Apollo 13 PDI [17:03:18] I tried 15 and Tycho last night [17:03:27] and? [17:03:53] unfortunately, Zerlina reaaaaallly doesn't like the way I'm doing the LR, and thinks that the DH is -81000 or so throughout the whole descent [17:04:03] but it's fine on 210 [17:04:05] oh [17:04:07] interesting [17:04:13] and holy cow 210 is nice compared to 99 [17:04:19] sure is [17:04:22] what does Zerlina do differently? [17:04:29] I have no idea [17:04:52] how do you choose which LGC version is loaded? [17:04:53] it must be something with how the variable servicer works [17:05:02] you don't load the same as NASSP automatically, do you? [17:05:13] oh shit [17:05:15] I do [17:05:16] because it's an Apollo 14 scenario, kinda [17:05:24] where the default is Luminary210A14 [17:05:29] riiiiight [17:05:30] okay [17:05:32] that's my problem [17:05:41] yep [17:05:48] I was not flying with Zerlina then :) [17:05:56] you mentioned that before and I totally forgot, heh [17:06:01] that's just due to our bad system [17:06:13] with the mission number [17:06:27] Apollo 14 was the closest [17:07:01] so using Zerlina still needs code changes on our side [17:07:08] whenever you want to try it [17:07:18] yeah, I'll make those changes tonight and try it [17:07:39] great [17:07:48] easy to figure out, haha [17:07:53] I might just make 14 point permanently at Zerlina on my builds, since I probably won't be flying any 14 landings [17:07:57] haha yes, thank you [17:08:05] I was really sad about that [17:08:20] I might have had that issue myself once [17:08:22] or twice [17:08:27] hehehe [17:09:08] is there any particular reason why you have the LM at an angle in the apollo 15 PDI scenario? [17:09:16] yes [17:09:22] better comm [17:09:26] ahhhhh right [17:09:28] okay [17:09:29] they had it at an angle in reality [17:09:36] for a bunch of missions [17:09:40] 17 even more extreme [17:10:15] oh [17:10:24] I recorded another video of an 11 landing [17:10:26] they invented that on the fly on Apollo 11 [17:10:29] showing all the new stuff working [17:10:29] 102:27:22 Duke: Eagle, Houston. We recommend you yaw 10 (degrees) right. It will help us on the high-gain signal strength. Over. [17:10:33] right, I remember that [17:11:04] nice, another video! The videos from Marc are almost daily by now, haha [17:11:06] https://www.youtube.com/watch?v=vuK2sAYLZbs [17:11:21] hahaha yeah, he's rushing to get them all edited and put out on time [17:11:22] has to finish up the videos of the last session before the next one [17:11:28] yep [17:12:07] Orbiter complains about your symbolic links [17:12:25] not sure that really hurts in any way [17:12:33] haha, it seems to be fine [17:12:41] but you can easily create them from the DX9 Client Advanced Setup menu [17:12:45] there is a button there [17:12:49] oh cool, okay [17:13:31] I fixed the master alarm being on upon loading, but only for new scenarios. Annoys me that it still happens for you :D [17:13:40] I might have a fix for it actually [17:13:50] maybe [17:13:59] er [17:14:01] actually no, nevermind [17:14:10] I also know how to fix it in your scenario [17:15:01] look for SUITFANDPSENSOR in your scenario [17:15:05] and add these two lines below it [17:15:11] CABINPRESSURESWITCH 0 [17:15:12] SUITPRESSURESWITCH 0 [17:17:06] oh, when the attitude maneuver prompt is up in P63 [17:17:10] the 50 18 [17:17:19] just to make sure you are in the right attitude, press PRO first [17:17:35] if the attitude is already correct then it will basically stay 50 18 [17:17:41] and not really do a maneuver [17:17:41] did I not do that? [17:18:18] oh, and when you watch a video [17:18:25] actually watch it and don't look at chat for a moment [17:18:29] or you might miss a PRO press [17:18:30] hahahaha [17:20:57] how did you like the view downwards on Mons Hadley Delta? [17:21:08] quite crazy flying over those mountains on Apollo 15 [17:21:22] yeah it is, it's awesome [17:21:52] you actually don't crash without using LR and also don't crash with the terrain model disabled [17:22:08] you just are 10k feet too high just after the mountain when you disabled the terrain model [17:22:20] it has to do crazy maneuvering but it still kinda works [17:23:45] oh and about the Zerlina scenario [17:23:46] hehehe [17:24:14] I couldn't come up with a good terrain model that was accurate in the last few nautical miles and also further away [17:24:28] so I only made it accurate in the last about 40 miles [17:24:34] you will see the DH go to -5000 [17:24:41] and quite quickly to +2000 [17:24:51] oh wow, big swing [17:24:57] and that's when you can safely incorporate [17:25:02] okay [17:25:13] because the terrain model doesn't cover the early part of the descent [17:25:18] or even the middle part really [17:25:53] the terrain is very rough, not so easy to come up with a good model [17:25:59] I was watching your video when trying to figure out the DH problem, and saw that you incorporated very late [17:26:02] so that makes sense :D [17:26:42] yeah, that's the reason [17:27:25] https://i.imgur.com/G6FXYqp.png [17:27:42] whatever unit that is [17:27:52] hahaha oh fun [17:28:17] meters [17:28:23] so that really only covers the last part [17:28:56] on most actual landing sites you have at least some parts of the descent that are very flat [17:29:16] Apollo 15 is very flat, then slope up, then giant mountain, slope down, pretty flat [17:30:17] did you figure out why P64 causes more alarms with TLOSS? [17:30:29] no [17:30:40] do you have smooth scrolling enabled for the FDAI? [17:30:45] how confident are we that they pressed PRO in P64 to allow redesignations? [17:30:48] I don't think so [17:31:20] ok, looks quite smooth to me and that steals a lot of performance [17:32:21] oh [17:32:26] 102:43:09 Landing point redesignation [17:32:44] 102:43:13 Attitude-hold [17:32:50] 102:43:22 Enter program P66 [17:32:54] and I think that's it [17:32:56] hmm [17:33:27] just allowing redesignations puts a huge load on the computer [17:33:56] I bet [17:34:07] I know the equations, it's a big chunk in the GSOP :D [17:34:21] hahaha [17:34:35] I'll try to find something on the PRO press [17:39:15] ".We proceeded on the flashing 64 and obtained LPD availability, but we did not use it because we really weren't looking outside the cockpit during this phase" [17:39:47] but, I think they wouldn't have done this immediately in P64 [17:39:59] and then pretty quickly after they switched to P66 [17:48:54] the LR issue when switching panels [17:49:07] I wonder why the LR reasonability test isn't picking up on that [17:49:14] hmm [17:49:16] good question [17:49:22] the LGC has ways to reject bad LR readings [17:49:53] well one check it only does post P63 [17:53:34] for whatever reason it only does the reasonability check on altitude in P64 [17:54:10] maybe it is for spurious data, which you only would expect when you are low [17:57:29] nice landing! [17:58:45] haha thanks [17:58:51] that one was okay [17:59:01] DSKY is missing some digits there in P71 [17:59:12] yeah, that happens if there's too much lag [17:59:19] right [17:59:22] so, TLOSS [17:59:26] not the worst I have seen [17:59:28] the LM was super jerky at the end of P64 because of the TLOSS, heh [17:59:35] I had DSKY blanks for 10 seconds during testing [17:59:58] so I think what you got there is still lighter load on the AGC than what actually happened [18:00:19] and the P66 throttle oscillations are about the same I am getting [18:00:27] I could see that I guess... but if I take it any higher I get waaaaay more alarms than the real mission [18:00:45] yeah, it was a really fine line between too much and not enough [18:01:09] are you using a keyboard with a numpad now or not? [18:02:19] no [18:02:19] engine stop also works with the minus key on the numpad [18:02:30] I am usually in "extended DPS nozzle" mode [18:02:30] ah, that would be very convenient [18:02:41] as soon as I see the contact light I hit engine stop [18:03:02] I think I'm going to map the ROD switches and engine stop to buttons on my joystick [18:03:23] that might be good, yeah [18:04:42] if you liked how smooth Luminary 1E works then Zerlina is even better. Incorporates ROD switch inputs far more often [18:04:49] oh man [18:04:55] I am very excited to fly it :D [18:05:35] man, I really should have realized I wasn't in Zerlina last night, haha [18:06:12] I even noticed that the nouns were different from what Zerlina's ASSEMBLY AND OPERATION INFORMATION section said they should be [18:06:23] and made a note to go back and compare against the listing to make sure I didn't have a transcription error [18:06:24] lol [18:08:11] yeah, sorry, mostly our fault, haha [18:09:19] this is adding more fuel to my wanting to make a Luminary version that combines all of the changes for 210 and Zerlina into one rope [18:09:35] oh yeah, landing with Zerlina will does that for sure [18:09:49] that might be a good way to take a mental break from all of this hardware stuff [18:09:55] :D [18:10:26] that one Luminary memo gives a crash course on using Zerlina, I am sure you have already looked at it [18:10:42] I did a while ago, but I need a refresher [18:11:32] #171 [18:11:54] I'll also have to ask Don if he has anything written down about his padloads [18:12:09] oh, did we never ask before? [18:12:20] mm, I don't remember [18:12:24] I didn't think we did [18:12:50] well we got it working anyway [18:13:12] indeed :) [18:13:28] after we got every single thing wrong on the first try, haha [18:14:42] yeah [18:15:13] I had to use a slightly earlier scenario and fly it to PDI again so that I could have one at PDI minus 5 min [18:15:33] and I had to fix basically all of the addresses I labeled NEW in the padload worksheet [18:15:53] hehehe [18:16:00] only my WIP scenario at PID- 2min ever got the fixed ones, at least before [18:16:04] PDI* [18:16:21] 3/4 scaling wrong, 1/4 value wrong :D [18:16:31] lol [18:16:38] once the anniversary is over, I'm definitely going to get more into NASSP, so I can do more than just fly PDI to landing [18:16:48] and eventually I would love for you to teach me how to do custom missions like this [18:17:13] like the one with Zerlina? [18:17:17] yep [18:17:25] let's say, it is a one way mission [18:17:34] hahaha [18:17:36] right [18:17:37] I didn't fly it super well [18:17:52] it was a normal Apollo 14 TLI [18:18:05] LOI 4000 ft/s instead of 3000 [18:18:26] that's a big difference :D [18:18:35] yeah, giant plane change [18:18:46] custom scenarios is very difficult right now to create, even for me [18:18:59] uh oh [18:19:02] so basically impossible for me, haha [18:19:30] I mean, it depends on the desired landing site [18:19:53] Alex once did a landing on the backside of the moon [18:20:07] he did a P22 on a spot he liked [18:20:18] oh wow [18:20:25] so it was already a site in-plane [18:20:36] for a scenario in lunar orbit [18:20:41] interesting [18:20:47] and then used those coordinates to land there [18:20:55] put them in RTCC MFD and targeted it [18:21:02] so sites in the same plane are not bad, it's just if you need a different plane that it gets very tricky [18:21:03] including landing site uplink to LGC etc. [18:21:17] pretty much [18:21:19] that's awesome :D [18:21:27] same plane or close is fairly easy [18:22:36] I guess learning the RTCC MFD is the main way to customize your missions [18:22:50] but it can't calculate e.g. lunar launch windows from Earth yet [18:22:55] or TLI presettings [18:23:11] that's what you kind of need for targeting other landing sites [18:26:31] just fly some mission, you will quickly notice how much an AGC depends on data that is being fed to it. Padload, many uplinks during a mission etc. [19:00:48] which are mission specific I mean [19:22:20] right [19:29:02] hahaha, Ron's updates on the LVDC stuff [19:29:28] "Simultaneous memory error" refers to simultaneous parity errors in a single address mirrored in duplexed memory modules.  This is also known by the acronym TLC, which is related in an obvious way to the description "Temporary Loss of Control" supplied by the documentation. [19:29:30]   However, "temporary loss of control" is quite an optimistic way of looking at it, because there is no method of recovery from it.  Far from being "temporary", the error is basically immediately catastrophic in the real world of the rocket, and therefore very permanent.  I have been told that the LVDC programmers called this the "Tough Luck Charlie" interrupt. [19:51:32] tough luck [19:53:27] did you see the additional pages? [19:56:37] oh [19:56:38] no [19:57:38] the EDD has a bunch about the TLC [19:57:43] it does indeed try to recover [19:57:50] going back to the beginning of the major loop [19:58:17] but I guess such a failure wouldn't happen if there wasn't some permanent hardware issue [19:58:53] new pages, now this is a bit more interesting... [19:59:51] looks quite similar to that pseudo LVDC code we found on NTRS [20:02:25] I recognize some symbol names from there [20:03:44] well, not very many [20:04:24] references to timebase 6, so definitely Saturn V [20:05:33] if it is from 1967 it might be related to the early AS-504 launch vehicle guidance equations document we have [20:06:44] SICFB, SIISA, SIISCA, sounds very Saturn V [20:06:53] so this might be a version that already could do TLI [20:13:50] neat ;D [20:13:50] :D [20:17:18] haha, Ron is doing a lot with very little [20:17:23] https://github.com/virtualagc/virtualagc/commit/793c0fab52d0dbfad12c6a0bf386d9e96d6504cf [20:18:24] yeah he is [20:19:24] probably hoping that developing tools to do all of this will help convince the anonymous source to give the whole listing :) [20:20:48] yeah [20:22:46] that would be awesome if it happens and it's a version that can do TLI [20:23:39] once we have it running we would probably start modifying it to have all the capabilities of all the different missions [20:23:50] hahaha [20:23:54] sounds like a job for Thymo :P [20:23:59] even better if we could find a Generalized Flight Program verison, so Apollo 12 and later [20:24:15] that was the major rewrite of the LVDC software [20:24:19] right, yeah [20:24:25] that would be amazing to find [20:24:41] it sounds like this 1967 version would be similar to getting Sunburst [20:24:45] or maybe Sundance, depending [20:25:00] difficult to compare [20:25:08] maybe rather like Sundisk [20:25:13] one of the suns [20:25:16] haha [20:25:47] to be honest, I didn't expect there to be any additional pages so quickly [20:25:51] that makes hopeful [20:33:22] good night! [21:35:04] That really does sound like a job for me [07:25:17] .tell indy91 Zerlina works! :D [07:26:25] .tell indy91 and it has motivated me to really start that Luminary 210 + Zerlina 56 rope... I'm about 100 pages into the merge [12:13:46] . [12:23:12] hey [12:45:12] hey Alex [12:47:33] tell indy91 and it has motivated me to really start that Luminary 210 + Zerlina 56 rope... I'm about 100 pages into the merge [12:47:35] that mad man [13:15:37] wow [13:42:40] I guess then we will have close to a proper Apollo 14 LGC software [13:45:25] I don't think that is the goal [13:45:51] the goal is to create the best possible LGC version with the features from Zerlina that never made it into Luminary [13:46:14] ah right [13:46:57] I guess the best way to get close to Apollo 14 would also be merging Zerlina and Luminary 210 [13:47:00] but differently [13:47:14] yeah [13:47:57] oh I was curious: "Implement maximum DV" any details on what that does? [13:48:51] nothing yet [13:49:05] but the RTE Earth-centered processor had a hardcoded DV limit [13:49:17] for TLC aborts it started with that and was never allowed to exceed it [13:49:37] but it seems for the TLI+90 they wouldn't apply quite as high a DV there [13:49:51] I think for Apollo 11 our TLI+90 gives a return 24h too quickly [13:49:59] ah I see [13:50:08] so I'll try to impose a limit there to get the right solution [13:50:20] haven't tested it yet, it's by default the old value, so nothing has changed [13:50:37] right [14:11:51] do you remember in the RTCC MFD code, where that debug string is to show the REFSMMAT components? [14:12:20] starting work to recreate the PTC REFSMMATs based on the SCOT [14:14:57] ARCore [14:15:06] line 2352 [14:15:23] or rather 2354 [14:15:33] the lower one of the commented debug strings in in AGC coordinates [14:15:53] ah thanks [14:16:24] Ill figure out the exact time that recreates it for every mission [14:16:46] I am thinking that should always stay the same regardless of when you launch in the launch window [14:17:01] so maybe we should have it as a fixed MJD in the constants [14:18:53] yeah, that would be a fixed MJD for a daily launch window [14:18:57] maybe even monthly [14:20:52] do you mind adding an MJD variable for the PTC REFSMMAT time in the RTCC MFD? [14:21:31] I can them figure out each for Apollo 12-17 [14:21:54] I can do that, sure [14:22:09] great [14:22:31] currently trying to figure out why LVDC 1B powered navigation is not as accurate as LVDC SV [14:22:38] it should be the same [14:22:46] it already starts before liftoff I think [14:22:53] weird [14:29:26] maybe it is just the SVCompare function [14:31:26] no [14:31:43] still becomes inaccurate fairly quickly [14:31:47] 3.5km at insertion usually [14:42:45] these are gravity terms, just after GRR [14:42:49] LVDC 1B: [14:42:50] S: -0.000002 [14:42:51] P: 0.015236 [14:42:58] Saturn V: [14:42:59] S: -0.000002 [14:42:59] P: -0.015278 [14:43:18] sign of P is wrong [14:44:18] which is weird, I took this from the EDD [14:52:55] ah it does a sign elsewhere [14:53:10] not the first time the EDD coordinate systems have confused me [14:53:29] the G-System points the Y-axis through the south(!) pole, who does that? :D [14:54:05] it's better now, but still not good as the Saturn V weirdly [14:54:12] maybe I just implement the complete EDD equations [14:54:27] and the Saturn IB LVDC also has no true orbital navigation yet [15:08:55] I guess it didnt really need it as much as the series 500 SIVB [15:09:31] btw I just realised there is already some REFSMMAT times saved in ARCore.cpp [15:10:00] Apollo 16 has the REFSMMATTime set to 166:-2:50 [15:10:13] which I verified with the SCOT and its correct [15:10:32] 166:02:50* [15:11:50] hmm but that variable gets modified if you say calculate a LVLH REFSMMAT with a deifferent time [16:03:20] I think I added that, for the 1-2 missions where I had to use that PTC REFSMMAT format [16:03:40] right, I guess it shares the time with the LVLH REFSMMAT currently [16:03:49] but how many LVLH ones do you calculate before a PTC one? :D [16:08:13] yeah [16:09:04] I have all the GETs for Apollo 12-17 now [16:15:28] I can just add them like the Apollo 16 one is for now [16:16:05] the only thing to keep in mind using GETs for PTC is if you have a launch delay, to subtract it from the PTC GET [16:19:17] right [17:06:22] morning! [17:11:32] hey Mike [17:12:00] AlexB_88, did you ever flatten the area around LC-34? [17:12:05] I think you did LC-39, right? [17:12:29] pretty sure I did bith [17:12:32] both* [17:12:38] hmm, ok [17:14:50] did I do a good job? thats entirely different question :D [17:15:18] well, I definitely tested it it afterwards and it seemed to be pretty flat [17:15:53] still haven't been able to figure out why the Saturn IB LVDC does powered navigation worse [17:16:16] bad alignment due to terrain that isn't flat owuld have been one possible explanation [17:17:49] right [17:18:36] PR sent [17:20:23] question for everybody: Where is Skylark :D [17:20:28] hahahaha [17:20:44] I'm going to send out an email to the list this morning begging them to bring rope modules to the brunch [17:20:56] so maybe we'll get lucky [17:21:33] also, making good progress on the Luminary 210/Zerlina merge... up to about 200 pages in or so [17:21:51] for the most part it's been straightforward; stuff was clearly added to either Zerlina, 210, or both [17:21:51] wow [17:22:02] only in a few instances is it confusing... like FLPAUTNO [17:22:07] in Luminary 210 that erasable was deleted [17:22:23] but in Zerlina it gained a new use in the landing guidance [17:22:36] so I need to figure out why it was deleted in 210, but presumably I'm going to need it [17:23:22] which constants are you going to use? [17:23:41] 210 constants, unless you say otherwise [17:23:46] I'm going for the latest and greatest of everything [17:23:50] yeah [17:24:09] and also the changes to make it work for more than the 1 period, not sure Zerlina got that update [17:24:32] I don't think it did [17:24:40] buuuuut along those lines [17:24:58] it would be very helpful if you could put together a little list of things that are in 210 but not Zerlina and vice-versa [17:25:04] things like that [17:25:14] it will help me make merging decisions :D [17:25:35] puuh [17:25:40] that's not so easy [17:25:43] hahaha [17:26:42] doesn't need to be exhaustive, just anything that pops into your head like that [17:27:20] sure [17:27:35] I'll go through the list of changes from 1D to 1E and check if Zerlina has them [17:28:00] thanks :D [17:28:26] oh shit we have that big binder from Don of Luminary 210 PCRs [17:28:38] that might be very helpful... I wish I had to scan the Luminary 1D one [17:30:44] I need to talk to Don about getting the rest of his stuff scanned [17:30:51] yeah [17:30:57] like the Apollo 7 Final Flight Plan :D [17:31:26] and the big folder just labeled "CDU memos" now that I'm trying to get a CDU working too [17:32:03] hmm, memo #215 makes it sound like there wasn't even a change to make the constant work for a longer [17:32:04] time [17:32:14] pretty sure I had seen something about that though [17:32:44] it doesnt really compare to before though [17:32:51] I have to go through the revision memos [17:33:22] I like how one of them memos calls the PRIO DISP light "super key release" light [17:33:28] http://www.ibiblio.org/apollo/Documents/contents_of_luminary_1e.pdf [17:33:31] PDF page 7 [17:35:07] FLPAUTNO was deleted from the FINDCDUW erasables and [17:35:08] a reference to it was changed to reference the previous erasable. [17:35:08] This moved 22 other FINDCDUW erasables up one. All [17:35:09] references to the erasable were deleted. [17:35:19] in memo 196 [17:35:30] haha [17:35:36] no explanation of why :P [17:35:42] other than it saved an erasable I guess [17:35:47] oh [17:35:54] only copied half of it [17:36:02] just read the memo, it has more on it [17:36:24] oh perfect [17:36:36] is "contents_of_luminary_1e" a giant file? Doesn't really load fo rme [17:36:52] ah, 200MB [17:36:56] shouldn't be so bad [17:37:20] must be a server issue [17:38:33] ah, I was looking at the wrong memo for the coordinate system stuff [17:38:34] https://www.ibiblio.org/apollo/Documents/LUM174-WR_text.pdf [17:38:40] this is the earlier one [17:39:05] seems to be only one PCR [17:39:15] 481 day limit on TEPHEM in lunar-solar ephemerides [17:39:26] PCR 1093 [17:40:23] and only in Luminary [17:45:47] hmmm [17:45:53] FLPAUTNO may be tricky to resolve [18:11:19] ok, I'm putting Apollo 7 on LC-39 [18:11:21] just to compare [18:12:52] nah, that doesn't fix it [18:13:14] no idea then [18:15:27] indy91, made a PR with the REFMMAT GETs, also included the inclination limit for Apollo 15 [18:15:50] and it's merged [18:17:52] thanks [18:17:56] gotta run! cya [18:33:40] ah, part 20 will finally be the part of the restoration series where you play around with the AGC! [18:34:12] looks like it yeah :D [18:42:38] and just like every good Apollo mission you need 3 DSKYs, judging from the last few seconds of todays video [18:45:31] at a bare minimum, yes [18:49:30] so smart of me to figure out that your erasable memory had the latiude of the MSC loaded, now if I could redirect some of that smartness to figuring out this LVDC navigation issue, that would be nice [18:50:29] yeah that was great [18:50:50] I did credit you for that in the recording, but I guess that part got cut :/ [18:50:54] haha [18:50:57] it's fine [18:51:14] the part where you got the dumped erasable all wrong was also cut [18:51:17] I sense a pattern [18:52:44] well I did just find some lines of code that should only run after GRR, but they ran before GRR before. But that still doesn't seem to fix it :( [18:53:16] it's only Saturn IB LVDC powered navigation. It's nearly identical to the Saturn V equivalent code, yet the Saturn V is a few kilometers more accurate [20:35:35] night! [03:20:08] .tell indy91 lol, some of these are annoying and I will need help testing them. I just found an instruction that is "CS" in Zerlina, but "CA" in 210. same label, comment, target address, and surrounding code. I think it might be a Zerlina bug? [03:45:14] .tell indy91 here's an interesting difference: Luminary 210 allows the astronaut to load N63, while Zerlina 56 does not. any idea why that would be permitted? [03:46:35] .tell indy91 that almost feels like a luminary bug... [07:59:33] . [08:00:32] hey [08:00:52] morning! [08:01:27] N63 is not in the list of nouns that can't be loaded in the program notes [08:01:31] so they at least knew about this [08:02:23] huh [08:03:13] very strange [08:03:27] I mean, I guess it doesn't hurt to load anything in N63 [08:03:30] maybe I should take the 210 version of that line then [08:03:50] not that you gain anything from it either :D [08:03:57] haha [08:04:15] so I've made good progress, most things have been pretty clear so far [08:04:30] I'm about 800 pages in... nearly halfway [08:04:43] but I've hit LUNAR LANDING GUIDANCE EQUATIONS which is almost entirely different [08:04:51] yeah, I remember [08:04:52] so progress is going to slow down for a bit [08:05:32] especially the P66 part of course [08:05:36] completely different [08:05:44] I do think now that this project was probably not my cleverest idea so far, and is probably going to be a disaster [08:05:48] but I'm too far in to go back now :D [08:06:18] starting this project right now was not the cleverest idea I think :D [08:06:23] in general I like it [08:06:32] haha, why not now? [08:07:22] oh, I was under impression you have some stuff to prepare for the next days [08:07:25] I figure it will be a good thing to work on during my 6 hour flight to florida [08:07:39] right [08:07:45] I've flown a couple dozen apollo 11 landings today too for practice :D [08:07:53] and we're getting together at Marc's tomorrow to pack and whatnot [08:08:18] ah. Current switch module properly repaired again? [08:08:22] I think I'm done making changes to the NASSP setup... it's working well enough now, no point in possibly breaking it [08:08:28] no, that is also for tomorrow [08:08:34] ah, ok [08:08:48] I have no last minute bug fixes your you anyway [08:08:54] apparently the diode that I had measured dead is suddenly back [08:08:57] the Apollo 5 one is the last one you "need" [08:09:03] oh right [08:09:06] I need to merge that in [08:09:43] oh, not so fun fact, most interesting things on Apollo 5 would have happened in darkness [08:09:55] oh yes, I remember that, haha [08:09:57] bug there is a DX9 Client ambient lighting option [08:10:00] but* [08:10:02] yep [08:10:17] ah right, you had tried that before [08:10:23] I have! [08:10:31] the only NASSP mission I have fully flown, to date [08:10:48] well, if you got deorbited you were probably missing the RCS tests [08:11:04] but they need uplinks to work [08:11:39] and happen hours later [08:11:53] not suuuper interesting, but they gave the DAP a bit more of a workout [08:11:56] well [08:11:58] they would have [08:12:11] ah [08:12:12] okay [08:12:25] plan didn't survive beyond the first maneuver, haha [08:13:27] I've mostly created PDI demo scenarios so far [08:13:46] but I guess it's the most interesting. And you have mainly practiced that :D [08:14:23] yeah, 99 landings are what we'll be showing in the museum demonstrations, for obvious reasons :D [08:15:05] I really want to fly more Zerlina / 210, but I also don't want to get too used to them, haha [08:15:13] yeah [08:15:37] I made a 131 scenario and it really confused me at first on how to incorporate LR data [08:15:52] they changed it after Apollo 11 [08:15:57] and then again for Luminary 210 [08:16:05] what do you mean, how? [08:16:14] isn't it always V57E? [08:16:28] nope [08:16:42] uh oh [08:16:43] in Luminary 116 and 113 V57 only shows N68 [08:16:55] and then you need to press PRO to incorporate [08:16:59] oh wow [08:17:00] or V34E to go back to N63 [08:17:23] I think Luminary099 only lets you do V57 in N68 [08:17:34] so the change required fewer keystrokes [08:17:48] that I think I picked up from Zerlina memos [08:18:11] so then in Zerlina/210 you just do V57E on the main N63 display and it incorporates, right? [08:18:31] yep [08:18:33] super easy [08:18:57] so forget all I said so that you don't get confused :D [08:19:06] hehehehe [08:19:17] see this is why I keep flying 11 over and over again [08:19:27] I will save the confusion for later :D [08:20:14] makes sense [08:20:34] you probably have flown 11 more than me now [08:20:40] well, the landing [08:21:18] hehehe [08:24:56] N63 used to be displayed in P12 as well [08:25:32] hmm [08:25:34] what's P12? [08:25:39] ascent [08:25:48] then they added a N94 for P12 [08:26:05] for obvious reasons [08:26:16] N63 had now DH between LR and LGC in R1 [08:26:30] that's the only N63 related change I can find [08:26:35] ah yes, not so useful during ascent [08:27:16] it's still not loadable in 131 [08:27:29] I don't thiiiink we have enough info to say whether it was in 178 [08:27:45] unless -- let me check my apollo 14 book [08:29:21] we have Luminary 178 flow charts [08:29:40] those don't have the noun tables in them though, do they? [08:29:45] it's a bit in the noun table [08:30:35] ah, right [08:30:56] yeah, it says it's on pages "none" [08:31:34] https://i.imgur.com/z2MN65c.jpg [08:31:57] old version of the noun [08:32:03] damnit book [08:32:09] well [08:32:14] maybe Apollo 14 still had that [08:32:26] oh yes, I think it did [08:32:35] and it doesn't have an asterisk... [08:34:00] I'm pretty sure it had [08:34:14] I think I came across the change in the Luminary memos [08:35:00] well I didn't find anything so [08:35:06] it was a typo/bug?! [08:35:22] who knows [08:35:43] it seems surprising that they would purposefully allow it to be loaded, when it couldn't be up through 13 [08:35:52] ah found the scaling change that made Luminary work for more than 481 days [08:36:01] PCR 1093, memo #187 [08:36:27] aha, nice [08:36:37] that is definitely a desired feature [08:36:56] brb [08:40:26] oh, one other thing that would greatly confuse me that I read in the Zerlina memos [08:40:40] did the polarity of the crosspointers change in the J-mission LMs? [08:40:44] nooo [08:40:47] he changed it back [08:40:53] it's in another memo [08:41:11] right, but he said he changed it back because a hardware change was made that accomplished the same thing [08:41:39] oh [08:41:41] right [08:41:41] hmm [08:42:07] I can probably figure that out from checklist setc. [08:42:09] etc. [08:42:14] The polarity of the cross -pointer displays was changed back [08:42:15] to what it always was, because the hardware change takes care of [08:42:15] reversing the LATVEL display, even in the LGC case. [08:43:53] it's at least not in the mission report appendix about configuration changes [08:44:43] hmmmm [08:45:12] during radar self tests the cross pointers are showing full scale high [08:45:23] so maybe in that part of the checklist I would see a difference to before [08:46:12] oh wait, the memo was before Apollo 14 [08:47:19] no, nothing [08:48:19] LATVEL [08:48:29] so only in one axis? [08:49:32] that'd be both, wouldn't it? lateral velocity? [08:50:07] oh [08:50:09] yeah [08:50:29] or is it? [08:50:38] looks up lateral in dictionary [08:50:50] haha yeah, lateral is just everything but vertical [08:50:54] also, http://www.ibiblio.org/apollo/Documents/contents_of_luminary_1e.pdf [08:50:58] page 10, bullet point 10 [08:51:06] not that document again [08:51:10] it doesn't load for me [08:52:14] "The polarity of the LATERAL VELOCITY cross-pointer using data sent via the LGC is reversed. This is a hardware change." [08:52:46] and lateral is only left and right [08:52:56] "Displays forward and lateral velocities" [08:53:03] hmmmmm [08:53:15] AGS only displays lateral [08:53:19] okay, interesting [08:53:33] let's see if the AOH description is different between missions [08:55:57] inconclusive [08:57:21] hmmmmmm [08:58:53] totally unrelated thing: https://www.ebay.com/itm/383044061410?ul_noapp=true [09:01:00] hmm, nice [09:01:48] oh also totally unrelated, but the LVDC has the latitude of Huntsville stored for flight simulation purposes. Probably not for gyrocompassing, but still, reminded me of your AGC :D [09:03:46] hahaha awesome [09:04:59] I really want to implement all the simulation features of the LVDC [09:05:09] what is more awesome than to simulate a LVDC simulation? :D [09:06:48] hehehehe [09:06:54] nothing that I can think of :D [09:08:03] so far I have nothing about the polarity change [09:08:10] but I'm still looking [09:09:38] it says it's a hardware change [09:09:49] but it wouldn'T really make sense that it only affects LGC data [09:09:53] yeah, me neither, just two memos from MIT saying there was a hardware change [09:10:01] or else if you switch to AGS or LR it would show it differently [09:10:24] Don's wording was "takes care of reversing the LATVEL display, even in the LGC case." [09:10:32] that implies to me that it affects all cases [09:10:56] oooooh [09:10:59] found something [09:11:05] LR self test [09:11:14] XPOINTER - UP, RT [09:11:16] for Apollo 12 [09:11:25] UP, LFT [09:11:27] for Apollo 15 [09:11:59] aha! [09:12:11] that sounds promising :D [09:12:43] sure does [09:12:50] we probably have it implemented the Apollo 12 way [09:13:07] we followed that activation checklist while implementing the LM systems [09:13:39] you definitely do based on how the crosspointer moves in the landing [09:13:57] with the change you want to fly towards the pointer to null lateral velocity rather than away from it [09:16:32] Apollo 15 MR has a cross pointer anomaly [09:16:41] but neither the 14 nor 15 MRs have something on this change [09:16:43] or 13 [09:16:51] or 16 and 17 :D [09:17:19] hahaha [09:17:46] strange that it is so unmentioned... [09:20:41] okay I really need to get to sleep [09:20:43] goodnight! [09:20:47] night! [14:13:24] hey [14:25:52] hey Niklas [14:27:13] still trying to figure out the LVDC issue with the Saturn IB [14:27:29] current test: just letting TB0 running on the launchpad for a few minutes [14:29:25] and that seems to be fairly accurate [14:29:32] 4 meters off in 3 minutes [14:31:57] I guess thats on par with the SV [14:32:30] yeah, I would say so [14:32:32] I should test [14:32:39] so that part isn't the issue [14:33:38] of course that might still be an initial alignment issue then [14:34:35] LV IMU should be exactly the same for both LVDCs [15:22:59] AlexB_88, I have too many PDFs [15:23:09] weren't you asking about the AS-506 Saturn V Flight Manual? [15:23:13] I had it all along [15:23:17] not sure where I got it from [15:26:29] it doesn't say that a guidance reference failure inhibits automatic TB6 [15:28:45] "With spacecraft control of the launch vehicle (guidance [15:28:46] switchover), T6 is initiated by the LVDC upon solving the [15:28:46] restart equation, or it can be initiated by the spacecraft [15:28:47] S-IVB IGNITION SEQUENCE START signal." [15:29:08] although I don't think the latter is actually working for Apollo 11 yet, from a CSM point of view [15:30:03] yeah, that confirms what I was thinking [15:30:16] do you have a link to it? [15:30:29] no [15:30:33] no idea where I got it [15:30:46] although [15:30:49] let's see... [15:30:51] Apollo 12 and later cannot do a CMC commanded restart, unless there is a guidance ref failure [15:31:59] morning! [15:32:12] hey Mike [15:34:31] hey [15:34:53] thewonderidiot, didn't you show me a NASA online archive once that is not NTRS? [15:34:56] with numbers like N6935801 [15:35:38] no, but given numbers like that we can more or less calculate what the NTRS ID would be [15:36:09] I have N6935801 but no idea where I got it from [15:36:31] I'm sure there is, or was something like NTRS where that is from [15:36:45] what document is it? [15:37:15] AS-506 Saturn V Flight Manual [15:37:35] oh, was it that NTIS website? [15:37:50] yes! [15:37:54] https://ntrl.ntis.gov/NTRL/ [15:37:55] that thing [15:38:20] yeah, I think that was it [15:38:30] yep, it has it there [15:39:30] AlexB_88, just put N6935801 there [15:40:14] ah thanks! [15:43:48] we need to spend some more time digging through here [15:44:06] N7010642 and N7010215, useful? [15:46:33] hmm, maybe [16:02:41] N7035826 is interesting [16:03:15] "Mission Training Program for the APOLLO Lunar Landing Mission" [16:04:31] seems to include many lesson outlines for various crew procedures and contingency scenarios [16:06:02] that one I already have seen [16:06:09] is probably on NTRS, or was [16:08:56] I think the conclusion we came to was that the overlap between NTIS and NTRS is very big [16:09:07] and there's just occasional useful stuff that isn't on NTRS [16:14:06] yeah [17:29:06] indy91, do you have a link to the Apollo 15 flight data file we got a while back? [17:30:50] https://readux.ecds.emory.edu/collections/emory-control:LSDI-Apollo15/ [17:34:18] thanks [17:34:27] Ill try to bookmark it this time [17:35:05] haha [17:35:23] I just downloaded it all immediately in the fear it might go away for some reason [17:43:07] yeah that was good thinking [17:43:35] I should probably hurry up, would sad to miss out on that [17:44:00] I'm sure it is fine and will stay [17:44:09] I updated Visual Studio and nothing builds anymore, just like last time. Awesome software. [17:44:40] I only updated it because it was also super slow today. Thought an update might fix that. How naive [17:48:13] same failure message as last time, but this time the fix from last time doesn't work [17:48:20] it's not even a build error [17:50:58] Error HRESULT E_FAIL has been returned from a call to a COM component. [17:59:42] got it building somehow [18:28:56] weird [18:49:50] IM setting up for an Apollo 16 mission, we seem to have most of the checklists for that one [18:50:26] the curveball will be a guidance reference failure during TB1 and manual TLI [19:47:52] sounds fun [19:48:16] hmm now my build is failing [19:50:08] sounds familiar :D [19:50:21] 27 succeeded, 6 failed [19:50:29] same error as I got? [19:50:43] which didn't show up as a error [19:50:45] but in the build log [19:51:21] C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppClean.targets(76,5): warning : Access to the path 'c:\orbiter1\modules\projectapollo\saturn5.dll' is denied. [19:52:05] hmm [19:52:14] you don't have Orbiter open in some way? [19:52:28] I checked, but no [19:52:30] but that's only a warning [19:53:05] im going to restart, brb [19:55:46] ok it works now [19:55:51] restarting did the trick [19:56:00] ah, nice [20:11:50] hmm my Apollo 15 launch -60s is not launching, engines dont start [20:12:55] ah wait I only fixes MESCA [20:12:58] fixed* [20:14:13] if I had realized immediately that this change would break old scenario I wouldn't have done it... [20:14:54] well its an easy fix [20:15:16] and if its too add realism im all for changes like this [20:15:19] yeah [20:15:28] and it's really the mixture of two issues [20:16:09] the maybe easier solution is to go to the ML in the scenario and increase the step by one [20:16:18] or STATE [20:17:39] but yes, the hold points for a unsafe condition are now very realistic [20:17:59] and I'll add even more stuff like that, like, all stages need to be in the right condition for it to continue the countdown [20:21:43] great [20:25:22] hopefully without breaking scenarios next time [20:25:46] night! [13:03:18] hey [13:08:50] hey Alex [13:09:00] got some LVDC listing news [13:09:32] Ron might get the full thing [13:09:50] his current evaluation is: classified? No, ITAR restricted? Probably not [13:10:03] and there are some more pictures of pages [13:10:08] and it's not for a Saturn V [13:10:35] I'm pretty sure it's for AS-205, when that mission was still assigned to AS-258 [13:11:01] and Ron says there are build errors and warnings, so it might not work as is but would need some fixes [13:11:15] or rather, assembly errors and warning [13:14:05] hmm interesting [13:14:24] so for a Saturn 1B? [13:15:14] yep [13:15:25] for the Apollo 7 launch vehicle [13:15:37] ah right [13:15:39] some new pages of the listing have actually some presettings [13:16:01] and they are identical to a AS-205 Launch Vehicle Reference Trajectory document from January 1967 [13:16:14] right [13:16:17] might not mean that the listing is from January [13:16:25] could be placeholder presettings [13:16:28] would it be possible to adapt it to the SV? [13:16:34] very difficult [13:16:35] but maybe [13:17:07] one step at a time, once there is an emulator we will start running it for our Saturn IB and then we will see [13:17:17] yeah [13:18:33] maybe with luck more sources will turn up [13:19:01] but this is pretty cool [13:19:48] I refuse to believe nobody has saved a listing for Apollo 11 [13:19:55] no way [13:20:14] or maybe there is something left from the end of the program, so Apollo 17 or so [13:20:39] somewhere out there. Once one listing is out in the open it will be much easier to pursuade more people who have them [13:21:02] persuade* [13:23:28] not that we really know of any more at this point [13:23:36] right [14:11:32] LM/CM deltaP gauge should read 0 psid on the pad according to the checklist [14:11:51] right now it shows full sacle (4 psid) [14:11:55] scale* [15:00:47] yeah, that's due to the tunnel being connected to vacuum and not to the Earth environment by default [15:01:09] right now it can only be connected to vacuum or the LM tunnel [15:01:34] we need a better support for whatever environment the CSM and LM are in [15:02:43] right makes sense [15:11:47] I'm looking into the attitude command logic of the LVDC [15:12:11] ever wondered why the attitude changes are so jerky? Well we are missing an important part of the LVDC code there [15:12:34] but the scheme that the LVDC is using only works if the minor loop is run at at even pace [15:12:45] right now it simply is the frame rate for us [15:13:01] the actual attitude changes would be quite smooth [15:13:28] so right now I am running the LVDC timestep at exactly 50 calls per second [15:13:36] as a test [16:06:17] 'Sup [16:06:20] Log ended by Thymo_, total logging length 3096262 seconds [16:06:21] .endlogging