[14:17:29] NASSP Logging has been started by n7275 [14:17:31] hey Niklas [14:18:21] hello hello [14:29:42] hello Tananarive, why do I not get any signal strength from you [14:33:16] ah [14:33:19] C-Band only [14:35:52] wait, is C-Band the same as VHF? Might be a dumb question... [14:36:34] or, C-Band is for ground tracking only and VHF is separate [14:59:26] c band would be radar I thought [14:59:53] yeah [15:00:40] we don't have any kind of user feedback for VHF signal strength [15:01:01] although it is calculated between LM and CSM [15:01:42] the antennas have proper polars and everything [16:32:24] I discovered last night that the CSM telemetry client has labeles reversed for H2 and O2 tanks temps [16:32:33] morning! [16:32:40] hey Mike [16:34:40] hey [16:34:45] n7275, ah, one more thing for me to change [16:36:37] I initially thought I broke something [16:37:10] -400F is a bit too cold for Oxygen [16:39:33] 2 questions: what needs to be tested for your pull request other than flying a mission with it, and have you had a chance to look at mine? [16:41:41] I don't think it needs any testing really, I know it works [16:42:28] if you really wanted to test every change you would need to launch, let CMC point sextant at Moon and Sun [16:42:40] and do a CMC controlled reentry [16:42:55] and I have not looked at your PR [16:42:58] will do in a bit [16:43:15] which one do you mean actually [16:43:21] radiative? [16:44:46] probably the N2 first because that's a bit more simple, but both should be ready [16:45:42] the radiative one is mostly a simplification and readability improvement, but I also added a feature [16:47:21] oh I actually summarized it on the pull request. I'm so glad I did that. [16:59:11] I think I'll do a quick Apollo 11 mission to test my padload update. I tested everything individually, even in-sim, but it is a bunch of changes at once [17:00:10] shortest mission, deorbit to the 1-4 area at 1:05h :D [17:00:36] ah no, not available for small launch azimuth [17:00:51] 2-1 at 1:22h [17:02:20] your N2 PR looks simple enough [17:02:36] what does that do? Just simulate a bit of the N2 stuff in the fuel cells? [17:03:40] yes [17:04:03] it will eventually provide a reference pressure to the H2 and O2 regulators [17:04:45] right, was looking for it to actually do something haha [17:04:53] but that just makes it simpler for now [17:06:45] it puts a realistic number on the telemetry display, and that's about it haha [17:07:10] good enough for me [17:29:31] :) [18:09:19] huh [18:09:32] I still had some local changes to the CSM telemetry client from ages ago :D [18:25:37] anything good? [18:27:06] ha, it feels like I stopped in a middle of a sentence [18:28:25] first I need to understand again how this all works [18:30:55] oh that's always fun [18:35:13] but seems like I just added two telemetry readings that weren't displayed yet [18:40:12] oh no [18:40:15] there is an old commit [18:40:56] I don't understand this, it's older than the last change [18:42:36] it's like I had two separate repos [18:43:42] 25 Nov 2018, my last commit on Github [18:44:02] apparently I did a PR with that [18:44:05] 14 Apr 2020 [18:44:08] got merged 15 Apr 2020 [18:44:16] but I had a local commit from 26 Nov 2018 [18:44:49] with some additional ECS telemetry [18:52:56] is VS2010 pretty much a necessity, or did you get it to build on a newer version? [18:57:21] I got it to build on 2017 actually [19:00:18] I don't know if the VS files on Github already have those changes [19:03:22] ok, all done except merging haha [19:03:27] LM client is already updated [19:16:50] what I can't do in VS is change the GUI [19:17:13] because then it seems to rewrite all of the code for it automatically [19:17:17] and doesn't build anymore [19:17:24] probably because it's still the old format or os [19:17:27] so* [19:17:43] so your issue with the label, I had to fix that in code [19:17:48] and not use the GUI editor [19:32:50] I never trust gui editors [19:53:05] of course I don't make that many GUIs and I'm kinda slow at it, so there's that... [20:00:20] hahaha I am in the same boat :D [20:00:49] nobody of us makes many GUIs that were created so long ago that it was barely buildable in VS 2010 for a while... [20:41:09] night! [14:05:33] hey [14:09:07] hey Niklas [14:26:53] ok, telemetry fixes all merged [14:35:02] wooo! [14:36:54] although I am already seeing something I don't like [14:37:14] SCS attitude error is not zero [14:37:18] maybe I got something wrong [14:38:37] hmm no [14:38:53] SCS scales that, so it should give 2.5V for zero attitude error [14:38:57] but it's not returning that [14:39:55] ah, it's not SCS, it's whatever is selected [14:39:59] so 2.5V exactly now [14:40:03] telemetry word is 128 [14:40:44] ah [14:40:58] it's in between [14:41:03] 127 = 2.49V [14:41:06] 128 = 2.50V [14:41:17] no [14:41:20] 128 = 2.51V [14:41:28] so it's getting rounded [14:41:57] and so zero attitude error is not shown as zero after unscaling [14:41:59] great... [14:42:09] but could be accurate [14:43:47] of course in reality there is the "unscaling" polynomial [14:45:32] yeah I guess you can't do much against this [14:47:08] a usual value for calibrated attitude error, on the ground side, is 127 = -0.022° and 128 = 0.017° [14:48:45] what the telemetry client can't do yet is scaling measurement based on some other telemetry. Attitude error telemetry is basically the same as FDAI needle deflection. So it differs based on the FDAI scaling, switch setting. [15:00:17] I'm somewhat tempted to try to emulate one of the programmable telemetry processors [15:01:21] maybe emulate is the wrong term [15:01:44] "write a plausible emulation of" [15:02:05] the most work you will have with that is tables [15:02:13] so many numbers [15:02:36] but assuming perfect calibration it should be a lot of copy and paste [15:49:41] the more I think about it though, it would probably just be an exercise in writing a jump table in an assembly language that I would have to invent [16:32:33] morning! [17:20:27] hey Mike [17:57:40] hey [17:58:32] good news: the board house finally started assembling the rope reader boards this morning :D [17:59:52] so like 11% now :D [17:59:58] 20%! [18:00:17] Windows installation progress bar would be proud [18:00:38] and bad news? [18:02:09] or only good news :D [18:02:26] only good news today! [18:02:45] yay [18:14:43] hi Alex! [18:14:46] lol [18:15:34] hey Alex, is was talking about you on the Discord [18:15:39] or more, about your keyboard [18:21:49] hey [18:22:31] haha [18:22:56] its actually Canadian English on my PC [18:23:31] my laptop keyboard is bilingual English/French [18:23:35] the keys to use the THC and the ROD buttons in the LM are always the two keys next to backspace, but they are different on each keyboard layout it seems [18:26:09] both my layouts have it as - and +/= [18:27:41] I got [18:27:48] ß ? \ [18:27:52] on the one key [18:27:59] ´ ` [18:28:01] on the other :D [19:02:54] I don't understand this [19:03:00] new Apollo 11 CMC padload [19:03:13] it's pointing about 0.4° away from the Sun [19:03:31] I was expecting 0.01° [19:03:48] maybe it is some fixed precision math that is causing the inaccuracy there [19:03:56] and maybe it's expected [19:04:07] I need to try it in our old Apollo 11 EPO scenario actually [19:04:13] maybe it was the same there already [19:19:28] hmmm, that's weird [19:26:58] I know that the calculation for the sun ephemeris is valid at exactly one time [19:27:01] mid mission [19:27:11] and a few days after or before that is starts breaking down [19:30:44] hello missing SM panel my old friend [19:30:56] hahahahaha [19:32:14] old scenario, Sun perfectly centered [19:50:25] whats the "preliminary" bool at the top of MCC calculations for? [19:50:46] doesn't seem to be used by anything [19:51:27] I use it on some missions [19:51:32] must have been a copy and paste thing [19:53:17] you can remove it if you dont need it for 12 [20:11:21] btw, we still haven't fixed some of the needles of some meters in the VC yet [20:11:27] CSM [20:11:50] mostly the O2/H2 tank pressures I believe [20:13:13] ah yes [20:13:47] also I think some knobs are reversed still [20:24:05] ah, figured out my sun problem [20:24:10] I did something bad with the sun velocity [20:27:25] when converting them to octals [20:27:32] cleaned up that section a bit [20:27:39] guess I did a bad job in that process [20:32:54] that drained my brain a bit. Good night! [14:24:37] good morning [14:26:12] hey [14:42:31] hey [14:42:46] hello [14:45:53] hey Alex [14:49:56] I did a bunch of P23s last night. I'm going to need new eyes if I do many more... [14:53:58] ouch [14:55:53] Ihave PTSD from P23s [14:59:58] whoever manages to implement semi-transparent line-of-sight for our sextant, so without alternating the view direction, gets a NASSP workplace health and safety award [15:02:04] I'm going to get a CRT monitor with a really slow phosphor until then [15:02:54] until then, doctors might use NASSP to check for epilepsy [15:06:30] nice side feature of some Apollo 7 MCC work I am doing, you can now get a Entry PAD for the 6-4 deorbit opportunity if you choose the abort option in the CAPCOM menu early enough [15:06:52] that's the shortest alternate mission they planned for :D [15:06:55] ah nice [15:07:15] they already got the target load and REFSMMAT anyway [15:07:20] and did a test with entering P40 [15:07:37] so for this GO/No GO area it's not much additional code [15:07:59] later on, I'll probably not add it for each deorbit opportunity [15:08:09] I think they had a go/no go about once a day [15:16:58] I am also working on block data right now for Apollo 12 [15:17:38] Im trying to integrate the midcourse maneuvers into block data 1/2 if applicable [15:18:32] not a problem for L/O + 15 as there is only one input SV [15:19:28] but for 25,35,45,60 there is potentially 2 SV's to input to the function, depending if you burned MCC or not [15:20:32] I dont think having 2 SV's plugged into "AP11BlockData" for one form is supported though [15:26:01] hmm right [15:26:30] in reality it was easy, you had MCC-2 on the MPT and then just ran the Abort Scan Table with the right choice of vector time [15:33:02] right [16:34:41] morning! [16:45:20] hey Mike [18:16:17] hey [18:16:38] hmm, just did the 6-4 deorbit on Apollo 7, I think I need to revisit the atmosphere issue again [18:16:51] our RTCC uses the 1961 standard atmosphere, Orbiter something more accurate [18:16:57] the difference is bigger than I would like [18:18:50] would those inaccuracies in the real RTCC? [18:19:00] were* [18:19:23] I'm pretty sure they started out using that atmosphere model, but by the time they flew manned missions they might have updated it [18:19:44] there are some additional tables from the mid 1960s for specific latitudes [18:19:49] they could have maybe used that [18:20:27] and a bit later, early 1970s, they upgrade to the Jacchia model that Orbiter also can use [18:21:05] the latitude dependent thing would just use different numbers, but the same equations [18:21:21] the main problem is, around 80km altitude the atmosphere in Orbiter is thinner than predicted [18:21:31] that means the 0.2g time on the Earth Entry PAD is off [18:21:45] and there is a PGNS go/no go check that almost fails because of that [18:22:18] and if I fly the profile that the deorbit burn and reentry was targeted for then I overshoot the target by nearly 100 NM [18:22:37] probably because of that issue at 80km [19:14:56] does the NRLMSISE model give better results? [19:19:03] hmm, I think it was pretty much the same as Jacchia [19:19:11] oh and actually, I have the NRLMSISE one enable [19:19:14] iirc it has seasonal variation, that the Jacchia model doesnt [19:19:55] I have a vague memory of this exact discussion between us a few months ago haha [19:20:02] yes yes [19:20:16] that was when I improved our Entry PADs [19:20:26] using some numbers from the RTCC reentry simulation [19:20:51] I didn't really find the proper fix for the issue then [19:20:57] and I wanted to add a feature for historical F10.7 data to Orbiter. it's all coming back to me now [19:27:52] Orbiter allegedly uses a constant Kp=3.0 [19:31:58] early 60s probably had a much higher average, so I wonder if that's where the higher predictions come from [19:37:22] not really seeing the big difference in my old graphs [19:37:29] need to check against Orbiter directly again [19:40:53] there was another issue where Orbiter underestimates the Mach number at high altitude [19:44:26] hmm [19:44:34] n7275, did you not update ALL old mission scenarios? [19:44:55] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Scenarios/Project%20Apollo%20-%20NASSP/Apollo%20-%20Mission%20Scenarios/Apollo%207/Apollo%207%20-%2020%20-%20At%20Entry%20Interface%20T%2B259h34m.scn#L39 [19:45:02] that's a scenario after CM/SM sep [19:46:16] I updated the energy, but not NASSPVER for those, since they were 7.0 scenarios [19:46:32] and other things were semi broken [19:47:06] right [19:47:14] well I am in the process of updating Apollo 7 [19:47:22] so they are getting replaced [19:47:37] just need to cheat to see a debug string :D [19:48:12] oh yeah.its probably preventing you from seeing it [19:49:34] not if I change the version number [20:46:26] :) [20:48:41] good night! [13:01:30] hey Alex [13:03:46] hey [13:50:45] how's your project with Apollo 12 MCC going? [14:05:43] quite well I have it working up to lunar landing [14:06:44] now starting work on lunar surface events [14:24:15] hey Niklas [14:28:03] hey [14:36:03] hey [14:36:57] indy91, I am forcing the TLC block data's to target an ATP line instead of a manual longitude [14:37:15] they are now very close to the real PAD [14:37:42] Apollo 12 [14:39:11] yeah, I guess the block data function there should really call the AST function. I'm also fighting with that right now, just so many layers of old to recent code... [14:40:51] but for now your solution is fine of course [14:41:18] right [14:42:47] there is a bit of hacky code here and there to make things work how I want them, but its all within RTCC::CalculationMTP_H1 [14:43:19] eventually as you update things in the RTCC itself I will take care of updating the Apollo 12 MCC [14:43:53] these are the times where I want to move to MPT only and drop everything else haha [14:50:23] I'm working on Apollo 7 MCC, maybe I should really try to go all in with the MPT for this one [14:50:58] yeah MPT only might make things easier MCC-wise [14:52:26] if you eventually do that with Apollo 7-11 I can always revise 12 too [14:53:52] so would that mean always using MED codes to access RTCC programs? [14:55:34] only internally [14:55:45] and the MCC could use the MED codes as much as possible, yes [14:56:09] for the MFD the better concept is probably to use buttons and dialog boxes for individual numbers [14:56:25] and then internally that uses the MED processing [14:57:40] right [15:09:05] interestingly Apollo 12 TEI-45 targeted a straight -165 [15:10:51] I wonder if it was just a coincidence the ATP solution gave -165, or was there EOM -165? [15:14:20] EOM target was 16.04°S 165°W [15:14:27] maybe the preferred longitude was exactly or as close as possible to -165, so they forced it just for the actual TEI on 12 [15:15:27] MPL is not at 165°W at that latitude? [15:16:40] ah I forgot how south that was [15:17:25] it used to be 165°W only for Apollo 8 and 10 only, or so [15:17:28] then it changed [15:17:35] so even if manual longitude isnt specified, MPL would find -165? [15:17:50] at LAT 16 S [15:18:02] yep [15:18:23] the target lines are customizable, which I have done for Apollo 8 so that it's only 165°W [15:18:42] otherwise it is 165°W for 0° latitude and south of it [15:18:49] ok makes sense [15:19:18] the early abort PADS on 12 must have more northerly latitudes [15:19:59] because its not exactly -165 for TLI+90, L/O +8, +15, +25, +35, +60 [15:20:44] and using the AOL target line in the RTE calculations gives almost the same longitude as the real P37 PADs gave [15:22:07] MPL target line* [15:22:15] AOL for TLI+90 [15:35:35] yeah if it varies between 165 and 175 then it should be 0° to 15°N [15:52:44] EOM targets were in some cases not on a contingency target line [15:53:01] for the line they wanted to stay clear of any landmasses [15:53:24] EOM target assumes everything has been going great, so they were sometimes closer to the recovery bases [15:53:36] like Samoa [16:07:53] right [16:59:29] morning! [17:02:46] hey Mike [17:03:05] what's up? [17:03:45] flying Apollo 7 [17:04:11] nice pic on discord [17:04:18] hahaha thanks [17:04:30] they sent that to me to check over before they finish it off [17:06:22] happy so far? [17:07:22] yes very much so :D [17:07:43] great :D [17:07:59] all the diodes that I've checked are facing the right way at least haha [17:08:10] don't see anything obviously wrong [17:08:47] diodes facing the right way, definitely important [17:09:23] also somewhat related, I realized something interesting last night [17:09:34] by dumping Sunrise 69, we also get Sunrise 45 for free [17:09:50] 2 for the price of one? [17:09:55] Sunrise 45 only had modules B21, B28, and B29 [17:10:13] for Sunrise 69 they added some new stuff (like gyrocompassing) in a new module B22 but didn't bother to update the other three modules [17:11:26] hmm [17:11:30] how does that even work [17:12:01] the only way I can think is that you can't start the new rev 69 stuff directly with an extended verb [17:12:07] right [17:12:19] directly via address and V30 [17:12:29] yeah I think you must have to use V30 or V31 [17:14:10] okay here we go [17:14:28] things included only in Sunrise 69: [17:14:36] AGC Self-Check Number Two in bank 6 [17:14:42] IMU Performance Tests 1 in bank 26 [17:14:48] and IMU Performance Tests 2 in bank 27 [17:15:10] bank 7 is also in that module but apparently has nothing in it [17:16:31] must have been a boring bank to manufacture [17:17:03] hehehe [17:17:23] it's probably actually truly unwired since Sunrise is so early [17:17:44] it doesn't have banksums yet, and there are unwired gaps between program sections [17:17:59] so I'm going to get crazy amounts of parity errors when dumping it [17:18:46] haha [17:19:06] also man we know a lot about Sunrise [17:19:18] this should be a very good disassembly :D [17:19:31] do we have procedures for it? [17:19:45] possibly, I need to look [17:19:59] but all of the Block I AGC Information Series documents were written about it [17:20:30] so we have things like this: https://www.ibiblio.org/apollo/Documents/agcis_21_system_test.pdf [17:21:03] oh that looks fun [17:25:33] yeah I'm getting pretty excited about Sunrise [17:31:34] I hope you aren't forgetting Block II ;) [17:39:41] hah, no, Block II is just complete, design-wise, so I've been working on Block I a lot the past few days :) [17:41:13] makes sense [17:41:58] for my padload work, I should do all the other CMC versions and misisons as well. It's not much additional work and I might not replace all padloads, but this process is good at catching typos as the old process was fairly manual [17:42:20] hah yes definitely [17:42:33] and I need to make the GUI prettier so I can actually feel ok with releasing it for everyone [17:42:37] sounds very similar to the process we use with program listing transcription [17:42:48] transcribe the code, transcribe the octals, fix both until they match [17:43:05] yeah, I was definitely comparing it bit by bit [20:09:09] I've been playing with some numbers and I think I have good solution for tunnel depressurization force [20:09:48] ooo [20:22:07] the challenge is, where do I do this in the code that makes it the least hacky [20:22:45] dockingprobe class? [20:23:04] or at least maybe call a function in the Saturn class from there or something [20:41:02] yeah probably [21:06:02] night! [12:43:08] good morning [12:50:02] hey [12:57:48] don't worry, I'm not looking to merge any IMU drift stuff for a loooong time [13:02:21] hahaha [13:03:11] I mean, as long as the bias and the bias compensation cancel each other out exactly [13:06:15] I would like to properly do all 3 types of drift + PIPA bias. [13:09:22] found a fun issue in early Colossus, state vector integration backwards for more than one orbit doesn't work [13:09:42] I uplinked state vectors time tagged at the the time of the Apollo 7 NCC1 maneuver [13:09:48] about 3 hours in the future [13:09:59] but if I do that and run P21 or V82 and such for current time [13:10:01] bad results [13:10:07] got fixed for Apollo 10 [13:14:46] oh interesting [13:16:11] it also means I might still not understand what time tagged state vectors even mean [13:16:45] in reality, for Earth orbit, they wanted to take drag into account as much as possible [13:16:48] which the AGC can't do [13:17:08] so state vectors should be as far in the future or shortly before maneuvers as possible [13:17:38] for NCC-1 it says it should be at TIG-12 min [13:34:51] good morning [13:36:07] hey Alex [13:39:33] hey Alex [14:52:59] is there an oapi function for supervessel center of mass vector? [14:55:11] GetSupervesselCG [14:56:57] on nice [14:57:24] what does that return if not docked? just vessel CG I hope [15:00:06] "If the vessel is not part of a superstructure, the return value is the vessel's CG, i.e. (0,0,0) " [15:00:14] it's a vessel API function [15:00:31] so the result will be in local vessel coordinates [15:00:44] with just one vessel that is always 0,0,0 of course [15:05:00] well that saves me a whole bunch of trouble [15:06:31] what do you need it for? [15:07:40] aceleration on the gyros due to angular velocity [15:09:12] ah fun [15:09:28] some LGC versions compensate for it I think [15:10:58] that would make sense [15:19:31] not for navigation it seems [15:19:38] just for measured thrust in P66 [15:19:40] PCN-1052, "P66 IMU/C.G. Offset compensation" [15:19:48] implemented in Luminary 1D [15:22:44] well that makes sense [15:26:51] its not like they were trying to make artificial gravity on the roof of the LM with sustained high pitch rates [15:32:31] of course you would have to include in your calculation that the IMU is not at the center of gravity [15:32:43] not of the LM alone either [15:32:51] docked of course not [15:33:39] there is the currentCoG variable [15:33:52] which defines the COG relative to the mesh [15:58:09] yeah. I was just hoping that I didn't need a pointer to a docked vessels cog vector. that would get messy very quickly [16:00:04]