[11:28:55] NASSP Logging has been started by n7275 [11:28:57] welcome back [13:50:29] hey [14:26:28] hey Alex [14:51:46] whats up? [14:55:07] Apollo 9 SPS-7, never ending story... [15:02:24] ah fun [15:44:05] morning! [16:00:38] hey Mike [17:16:11] I will simplify the input guide a bit I think [17:16:36] especially the TLC MCC [17:17:16] if the launch is on time no need to change any parameters [17:17:25] except for matching the LOI TIG [17:36:52] somehow I managed to make a whole bunch of changes and had my code compile and run on the first try. weird. [17:46:15] not that it did what I want or anything... [18:38:36] haha, it's... progress? [18:41:23] I'm an idiot lol [18:41:47] I changed from the multiple clbkGeneric calls to just calling with a struct [18:42:21] it's giving me gain, power and relative position back forom the transmitters [18:42:47] and I'm still calling getGlobalPosition on R_E [18:42:59] which never gets updated [18:45:21] That is some code that Jordan is working on [18:45:59] basically scans every NASSP file and renames it in a specific scheme, because of the lower case, upper case problems that people running NASSP in Orbiter on Linux are having [18:46:33] there are two reference files, lists of file names basically, generated from the git inventory of files [18:46:58] Jordan said I should share it, in case someone wants to look at it and give some feedback [18:52:01] that looks like he's put a lot of work into this. [18:55:42] yeah [18:56:02] I think in the end the update will be pretty simple [18:56:18] deciding all the file names will be lots of work though [18:56:41] but then you run this code once, make a PR and we spend a few days checking that everything matches [18:57:04] and because Window doesn't care about lower/upper case much the next NASSP release will just overwrite all the files [18:57:14] Windows* [18:57:18] and nobody noticed that anything even changed [18:57:22] hopefully :D [18:57:41] but it will likely be looots of changed file names [18:57:55] DDS and dds and CPP and cpp are just the beginning of the inconsistencies [20:14:03] ugh, reacq mode still has a bug [20:14:32] tries to drive to manual pos on scenerio load [20:30:45] fixed it. [20:30:48] again [20:33:00] you have your reacq mode, I have my Apollo 9 SPS-7 targeting [20:34:42] or maybe better comparison, the LM RCS thruster failure logic... [20:37:13] I'm sure I'll have to fix it again some time haha [20:39:14] hey, just pushed a commit to my branch, could you look at it. it allows the stations to function with gound tracking off, just disables the messages [20:40:13] I guess the other thing we could do is just always have ground tracking, but not necessarily mission tracking on. not sure if that would break stuff. [20:52:44] *ground [20:59:01] woo, I think the rope reader FPGA, firmware, and GUI are all pretty much feature-complete and ready to go [20:59:06] just need the driver board now [21:02:06] n7275, I'll give it a good testing tomorrow [21:02:22] sounds good! [21:02:33] thewonderidiot, it's really coming together! [21:02:58] thewonderidiot, nice! [21:04:22] my padload generator supports Artemis fully, I had started on Colossus 237, but it will be able to generate one for Comanche 67 with one mouseclick. Of course it's still some time away, but I'll be ready. [21:05:38] night! [23:43:37] AlexB_88, if you're still taking requests for mesh work, any chance we could get an EVA light boom and spotlight door? [23:46:48] ah for sure [23:47:42] it might not be right away though, Im getting ready to fly Apollo 16 soon, but I will put it on the list! [23:53:44] that's cool [23:54:00] did you see that we have functioning lights now? [01:50:52] yeah I did, they look real good :) [01:51:01] night! [02:05:46] thanks! [10:22:41] hey [10:24:00] hey Matt [10:24:08] I don't like your saving/loading code for the AOS flags [10:24:28] I'm doing a pull request-ception and will have an update ready shortly [10:27:15] ahh okay, I knew there was probably a better way [10:30:42] I'll make use of our custom saving/loading functions for int arrays [10:36:27] I wonder if we can get also get rid of TransmittingGroundStation [10:36:37] maybe that can only be an integer? [10:36:42] the number of the ground station? [10:37:30] that would also simplify things [10:37:58] I'll try it, if it doesn't look good I'll reverse it [10:42:18] so instead of having a pointer to the transmitting ground station we would have [10:42:20] GroundStations[TransmittingGroundStation] [10:42:25] to access the data [10:42:35] is that fine with you? [10:42:47] simplifies saving/loading, too [10:43:10] well, that's the main advantage [10:43:18] otherwise it doesn't make much of a difference [10:44:18] hmm, found a problem with it [10:45:13] but not terrible [10:45:16] in mccvessel [10:45:17] mcc->TransmittingGroundStation->SBandAntenna [10:45:28] would become [10:45:31] mcc->GroundStations[mcc->TransmittingGroundStation].SBandAntenna [10:58:50] that should work [10:59:01] I'm fine with one less pointer [10:59:57] the nice thing is any logic like "TransmittingGroundStation == NULL" stays the same [11:00:14] because if it's not transmitting the integer is just 0 [11:03:28] nice [11:04:54] if I had to actually change some of your logic I wouldn't do a change like thid [11:14:19] https://github.com/n7275/NASSP/pull/42 [11:16:21] the scenario saves [11:16:22] MCC_GroundStationAOS 5 1 [11:16:23] MCC_GroundStationAOS 29 1 [11:16:30] for the two Honeysuckle stations for example [11:16:40] and it only saves if the station is in AOS [11:16:44] saves a bunch of scenario lines [11:16:51] and then [11:16:54] MCC_TransmittingGroundstation 29 [11:17:32] instead of the name [11:31:48] and PR-ception does work [11:31:49] much cleaner [11:32:15] awesome [11:32:17] yeah I was looking at the loading code and just thought "no" :D [11:32:28] now I can actually test the update [11:33:23] lol [11:33:37] I probably should've thought that while writing it [11:34:47] I mean, I think that about my own code 90% of the time "there has to be a better way..." [11:37:41] ok, so scenarios with no MCC vessel aren't loading [11:39:01] OMNI::TimeStep [11:39:05] VESSEL4* MCCVessel = (VESSEL4*)oapiGetVesselInterface(oapiGetVesselByName("MCC")); [11:39:19] oapiGetVesselByName already return null [11:39:32] so I guess oapiGetVesselInterface causes a CTD [11:40:01] null the MCCVessel pointer in the constructor, get MCCVessel pointer in the Init function [11:40:39] and then in the timestep it can still check if MCCVessel is valid [11:40:50] just the VESSEL4* MCCVessel = (VESSEL4*)oapiGetVesselInterface(oapiGetVesselByName("MCC")); [11:40:52] line causes issues [11:44:21] oh whoops [11:44:29] I check for that in other places [11:44:35] but not there [11:48:00] I have a hunch that there could be a Space Shuttle Vessel release on Tuesday [11:48:18] oh that would be cool [11:48:45] if it's not on Tuesday then I will say, I meant next week Tuesday [11:48:46] like, this Tuesday? or Orbiter-Tuesday? [11:49:26] GLS contacted me a few days ago about including references to the FDO MFD, so I think it's very close in any case [11:49:43] I guess I will put that in my old SSU install [11:54:12] I think the last time I had I shuttle addon install was with Orbiter 2006 [11:54:24] *installed [11:54:35] will be nice to try out [11:55:26] remember STS Payloads [11:55:33] I do. [11:55:51] on some old hard drive I still have a working 2006 install with that. I think it was hard to set up, so I never deleted it haha [11:58:34] I have a hard drive like that somewhere. it has a megastructure that I built out of Greg Burch's Space Station Building Blocks, piece by piece. [12:01:03] the Greg Burch addons were great, that's what I started writing some lunar ascent/landing autopilots for [12:02:03] https://www.orbiter-forum.com/resources/launch-and-rendezvous-autopilot-for-greg-burchs-lsts-in-lua.3186/ [12:03:08] I knew C++, but couldn't figure out Visual Studio to write a MFD for Orbiter yet, so I used lua instead :D [12:03:41] that is very cool. I may have used this back in the day [12:03:52] I'm pretty sure I did in fact [12:04:57] did you just add a like to it or was that 9 years ago? :D [12:05:59] that was just now haha [12:06:39] I want to do more with lua, you can do some fun things scripting and NASSP supports it [12:06:55] like throwing switches even [12:07:02] CMC failure simulation by pulling the CBs [12:08:03] or tutorials [12:11:19] can lua send commands for the hand controllers? [12:14:54] hmm, probably not [12:16:07] maybe if they were implemented as PanelSDK switches [12:16:31] potentially you could use some Orbiter API call that has lua support [12:25:25] hey Alex [12:27:09] hi Alex [12:29:42] hey guys [12:30:27] I've got two more VC issues for you haha [12:31:13] ORDEAL in the CM, text on alt set rotary is inversed [12:31:39] and there is an issue on panel 382, two switches are interchanged, look on Discord about 5 hours ago, there are screenshots [12:45:27] ah yes just saw [12:46:56] probably just need to reverse the axis [12:47:14] I have a few for you too :D [12:47:58] I had a maneuver on the RTCC MFD yesterday and when I tried to "freeze" it (M62 I think)... CTD [12:50:29] and the other one was in the RTE digitals, there is a "DV" button in the bottom left, when I clicked it CTD [12:52:08] ah yeah freezing maneuvers, that doesn't work right yet, but I should make sure there is no CTD [12:53:39] how did I screw up that DV display though... [12:54:29] did you have a calculated RTE maneuver when you went to that page? [12:54:43] DV button leads to a display shared with the deorbit targeting btw [12:54:59] RTE Digitals has no DV vector display, but that page has one [12:56:24] hmm I definetly had a CTD last night when hitting the DV button... but I am having trouble reproducing it right now [12:56:36] let me go back to the same scenario and conditions [12:57:07] I think it was an Apollo 15 pre-LOI with PC+2 on the RTE digitals [12:57:12] MPT active [12:58:02] I also had stored the LOI preferred REFSMMAT into DMT [12:58:16] and referenced DMT for the PC+2 [12:58:55] I'm storing the displayed data in a vector to prevent that every display takes up memory even if it isn't used [12:59:02] It's probably an issue with that [13:01:17] is the DV page so you can immediately build an abbreviated P30 PAD? [13:02:01] I'm just implementing a real display they had. And it was slightly annoying that you couldn't see the DV vector until you moved the RTE solution to the Maneuver PAD [13:02:46] but yeah, maybe you have enough information with RTE Digitals and the Retrofire External DV displays to build the abbreviated PAD [13:04:07] yeah it does look convenient for that [13:04:21] can't replicate it sadly [13:04:54] ah but the display data isn't all initialized to zero [13:04:59] it shouldn't show any them [13:05:04] but maybe there is a bug there [13:08:53] or the apoapsis height exceeding the display limit or something [13:12:08] hmm yeah, it could be something uninitalized there [13:12:17] so CTD would be random [13:15:17] but it's Earth referenced, makes no sense... [13:18:47] was it a fast PC+2? [13:19:12] with reentry speed constraint increased to 37500 ft/s? [13:19:54] yeah [13:19:59] aha! [13:20:11] I can replicate it now [13:20:19] hyperbolic trajectory [13:20:25] so there is no apogee [13:20:39] and it should be nulled for that, but isn't, somewhere [13:22:59] ah yes, I can reproduce it too with the fast PC+2 [13:23:20] if there is no apogee it sets it to the maximum double precision value [13:23:25] and the MFD tried to display that [13:23:29] that's the CTD [13:30:17] interesting observation: if I set a breakpoint in any of the CSM telcom timesteps the two variables hSMpanel4 and ApolloExploded always show up as in scope [13:46:23] huh, hSMpanel4 [13:46:26] that's suspicious [13:47:41] but I forgot which one becomes invisible occasionally [13:47:44] 1 or 4 [14:01:23] 4 [14:05:16] at least the last 3 times it's happened to me it's been 4 [14:05:45] oh it's always the same one [14:05:52] so [14:06:01] suspicious :D [14:06:52] there's a struct in a union for the A13 stuff I bet that's related to why this is so hard to debug [14:08:23] the type punning energy there close to that of the EQUIVALENCE statement in alcsbt [14:14:16] equally annoying issues [14:25:23] I think I can stand to put about 1 hour in per month on solving that one. on to something else [14:44:57] indy91, is there an "MPT" method for calculating a landing site REFSMMAT? [14:45:56] in other words, with the MED codes, instead of using the traditional REFSMMAT page [14:46:53] I would imagine one could use G03 and figure out the GET over the landing site? [14:47:28] there is a lunar surface alignment display, which we don't have yet [14:47:32] that's what they used [14:47:35] ah [14:48:12] I have that in my GUIDO loop notes [14:48:14] 106:58:55: Initialize the LSAD, compute a LLD, liftoff time 124:22:07, also vector time [14:48:21] 107:00:25: LSAD ready, LLD008 REFSMMAT generated. [14:48:32] 107:00:36: Transfer LLD008 to CSM MED [14:48:33] 107:01:20: Transfer complete, CSM MED005 [14:48:34] 107:01:40: YAW: CMC REFSMMAT update, MED005, address 306, type 2, Goldstone and Hawaii [14:48:42] LLD is Lunar landing(?), desired [14:48:45] that's the LS REFSMMAT [14:48:56] the rest of the operations there is to move it to the CSM REFSMMAT locker [14:49:01] and then generate the uplink to the CMC [14:49:44] ah ok [14:50:21] and I guess the display would use the ephemeris, to get the CSM state vector which is used to define the orbital plane of the LS REFSMMAT [14:50:29] so that would be a "MPT mode only" display I guess [14:57:43] so when I do a landing site REFSMMAT right now it stores it directly to CUR [14:57:50] I think [14:57:57] yeah, every REFSMMAT is stored directly in CUR [14:58:09] at least every one calculated on the REFSMMAT page [14:58:15] not e.g. the one from the RTE [14:58:26] so, if I want to not overwrite my previous REFSMMAT, say PTC, can I temporarily transfer that one to another slot? [14:58:37] that is done automatically [14:58:49] when CUR gets updated the last CUR gets saved as PCR [14:58:53] previous CUR [14:59:05] ahh [14:59:12] ok that is convenient [14:59:39] I guess they were also afraid of overwriting that by accident :D [14:59:54] I think for MCC-4 it is sometimes useful [14:59:56] or you can move your CUR to some other slot with G00 [15:00:20] MED is the one where they always put something they didn't know a better place for [15:00:35] like the landing site REFSMMAT [15:00:42] right [15:00:47] CSM REFSMMAT locker has no place for a LS REFSMMAT actually [15:16:37] the RTE maneuvers placed on the MPT do not listen to the MPT vehicle config, ie. if you do CSUX it will be an undocked maneuver regardless of MPT config correct? [15:23:21] there should be logic in place that makes the RTE maneuver an undocking maneuver if that is required [15:23:56] and it should return with error if you e.g. choose a RTE docked maneuve but the previous config was CSM alone [15:24:21] ah ok [15:25:33] so in this case no need to e.g. include an undocking maneuver as direct MPT input [15:33:50] right [16:17:55] for some reason signal strength reads off scale low over telemetry but only when using the HGA now. what did I break [16:25:07] never mind [16:33:04] issue is with the telemetry client [16:35:58] oh [16:36:32] only the client or something with generating the telemetry [16:46:05] I think my scaling is just off [17:00:40] return static_cast( ( ( data - low ) / step ) + 0.5 ); [17:01:23] the +0.5 is probably fine in most cases [17:07:48] but for values very close to the top of that range it should overflow that unsigned char right? [17:17:03] changing it to: [17:17:05] return static_cast( ( ( data - low ) / step )); [17:17:08] fixes the issue [17:17:21] but why was it like that in the first place? [17:23:28] oh that's been there forever, I'm sure there is a reason [17:24:38] which measurement ID is this? [17:26:40] CT0620E? [17:28:55] there is a special note on that one [17:29:00] in the calibration curves document [17:29:58] "this measurement will not be presented in engineering units but scaled from 1 to 254 PCM counts." [17:31:01] are we maybe also generating all telemetry wrong? :D [17:31:08] 0 and 255 seem to be a bit special cases [17:31:55] that's in scale_data [17:32:35] easy enough to change the PCM class to go from 1 to 0xFE [17:32:44] client would need to change too though [17:32:51] probably [17:34:54] it's difficult to say in the calibration curves, even those with a linear function are calibrated [17:38:29] I do think that 0.5 needs to come out though [17:39:38] anything between 99.8% and 100% of max will go through as 0% [17:40:04] and then over 100% will be 100% [17:40:29] yeah [17:40:39] what I am seeing for e.g. voltages scaled 0V to 45V [17:41:05] all calibrated closely to each other, no big differences between several measurements [17:41:15] 1 is close to 0V [17:41:21] and 254 close to 45V [17:42:05] the calibration curves should take care of nonlinearities in transducers, shunts, etc [17:42:09] yeah the 0.5 will cause all offscale high measurements to be send as 0 [17:42:24] I think? [17:42:28] nope [17:42:32] with the new time uplink features, I think I can re-write the "liftoff time update" procedure I wrote in the inputs guide [17:43:08] just the things between 255.5 and 256 [17:43:25] oooh because we have special code [17:43:37] because there's the return right at the beginning of scale_data [17:43:44] yeah [17:44:37] at least it should be a fix just for scale_data [17:44:42] so minimal change on NASSP side [17:45:48] the code you were quoting earlier, where is that in the telemetry client? [17:46:27] AlexB_88, yeah I think that update is now somewhat comfortable. Not yet the big Apollo 16 change for their 24 hour early return [17:46:43] it doesn't allow a negative liftoff GMT [17:46:55] instead you have to change the liftoff day to one day earlier [17:47:05] on the RTCC MFD config page [17:50:24] n7275, even the step calculation seems wrong if we would use 0 to 255 [17:50:32] I think what we need there is 253 and not 256 [17:51:13] and then... [17:51:18] static_cast( ( ( data - low ) / step ) + 1.0 ); [17:51:29] I don't know about the rounding though [17:52:34] using that conversion it would be, speaking in double, 0V -> 1 and 45V -> 254 [17:52:40] in the 0 to 45V scaling example [17:56:17] indy91, is it quite simple just for a REV2 crossing update? [17:56:39] and I think they did it again in lunar orbit [17:57:08] well coming up with the delta time for the update is still the hard part :D [17:57:16] if the meridian crossing differed by more then a minute from the reference time [17:57:28] yeah needs the MPT and such [17:57:48] hmm [17:57:57] but when you have the DT, you just plug that into the Liftoff uplink page? [17:58:01] doesn't the MCC processor write a rev 2 crossing time? [17:58:09] to the online monitor [17:58:13] hmm [17:58:30] and then later what works is to use e.g. the nav check PAD [17:58:47] ah right [17:58:51] you plug in a time and you get the longitude [17:59:02] is that MPT compatible? [17:59:26] nope [17:59:36] but it can be made compatible [17:59:49] a bit like a mini checkout monitor [18:00:25] the better way with the MPT, in lunar orbit already, is the FIDO orbit digitals [18:00:36] you can tell it to compute the time of a longitude crossing [18:00:59] shouldn't step be 254 until we can change the client (or its replacement)? [18:01:53] the client should be fixed in any case [18:01:59] clients [18:02:03] so should NASSP [18:02:20] isn't it all going through one function? [18:02:38] so it's just one modified function in CSM, LM, CSM client, LM client [18:02:58] indy91, if I remember, orbit digitals is not MPT compatible? [18:03:12] uhh you mean, not non-MPT compatible? [18:03:21] it only works with an ephemeris [18:04:06] n7275, ok so there is a reference table in the calibration curves document [18:04:11] 1 = 0% and 254 = 100% [18:04:23] ah I remembered wrong [18:04:29] 253 = 99.6% [18:04:35] but what happens at e.g. 99.8% [18:04:40] 253 or 254... [18:05:15] maybe it should be normal rounding [18:05:25] or else only exactly 100% results in 254 [18:06:02] static_cast( round(( ( data - low ) / step ) + 1.0) ); [18:06:20] with scale 253 [18:07:53] then we just need to figure out unscale_data in the clients [18:09:02] double step = ( ( high - low ) / 256.0); [18:09:02] return ( data * step ) + low; [18:09:06] should be... [18:09:27] double step = ( ( high - low ) / 253.0); [18:09:41] return ( (data-1) * step ) + low; [18:11:00] I don't like that we need round because that function gets called many times per timestep [18:11:10] but maybe unavoidable [18:19:56] hmm [18:20:11] isn't the +0.5 and then static cast to char like rounding? :D [18:29:50] errr kinda lol [18:30:56] yeah I am sure that's the reason why we have it [18:32:22] just that the scaling is wrong [18:32:50] which is what you said 2 hours ago :D [18:33:44] uhhh [18:33:56] you deleted the +0.5, that is not correct [18:34:53] don't include this change at all in your PR please [18:34:57] that's a very separate issue [18:51:40] does the "CMC liftoff time update" uplink update the TEPHEM as well? [18:52:02] I calculated I need to adjust my time by -42 seconds [18:52:45] this is Apollo 15 TLC at 53 hours GET, at the scheduled time for the liftoff time update [18:52:46] time increment updates AGC clock only [18:52:59] liftoff time update updates: TEPHEM, clock, state vector timtags [18:53:01] right [18:53:09] time tags* [18:53:18] ok [18:53:49] so if I understand I just need to put INP: -42 seconds and uplink that [18:54:13] yep [18:54:25] careful with the sign [18:54:35] does your GET need to be larger or smaller [18:54:49] if larger then the liftoff time needs to be earlier [18:54:57] and earlier is a minus DT [18:55:42] the checkout monitor said I will be at -177.89 at the reeference time in the FP [18:55:54] longitude -177.89 [18:56:37] the uplink won't change the liftoff time in the RTCC automatically [18:56:52] you need to sync that, but there is a button for that next to the RTCC liftoff time on that page [18:57:06] on the uplink page, same button as the config page [19:02:51] right [19:09:33] was -42 correct? [19:27:53] +42 [19:28:36] indeed I had to change the sign [19:29:00] I mean I could of skipped it as its under a minute difference [19:29:06] right [19:29:34] but I will say that it would be a lot easier if the nav check pad was MPT compatible lol [19:29:57] yeah, that should be easy [19:30:12] checkout monitor is the same, just takes more inputs :D [19:31:21] you also have an extra conversion to do, delta-longitude to delta-time [19:32:17] ah I guess its the same for the nav check pad [19:32:27] but yeah as you said, less inputs :D [19:34:53] easier to do trial and error to get the 180° with less inputs, for sure [19:35:14] I think they did add a longitude search option to the checkout monitor at some point [19:35:37] not in any of our documentation, but I think the Apollo 13 FIDO used that [19:36:01] that would be useful [19:36:40] not sure how hard that is to add [20:05:20] I think I could basically use the same logic as the Orbit Digitals [20:10:06] indy91, I'll reset to the previous commit and push a little later. you're right, I've got myself a little off topic here [20:14:48] sorry to make the PR list bigger [20:14:51] PR sent [20:23:14] n7275, but you are right, it's not a minor issue, we should properly fix that everywhere very soon [20:23:35] issue without consequences but still, quite wrong [20:24:09] AlexB_88, no problem, I'll just make the list smaller [20:25:35] by merging it [20:35:54] I think I have a bit more focus on the "how" of our telemetry, than I do on the "what do we actually want this to look like eventually" part. lots of chicken and egg paradoxes in the planning stages though. [20:49:23] Your current PR should enable us to do the Apollo 9 HGA tracking test properly. I think that is a good focus to have there. [20:51:07] AlexB_88, if you want to reduce the number of PRs, I do have a nice and small one up [20:51:44] tweak number 13478278 to the SPS-7 targeting [20:52:21] and the other thing, our RTCC does not use the same coordinate system as the real one (yet) [20:52:41] that also means the REFSMMAT shown on the REFSMMAT page is not the same as would be uplinked [20:53:07] in fact, it differs from the one shown on the uplink page, which is the uplink coordinate system [20:53:35] so now I am hiding the fact that the coordinate system is wrong by showing REFSMMAT in uplink coordinates [20:54:04] so it's the same as on the uplink page [20:54:18] and it's showing the REFSMMAT code now, e.g. CUR005 [21:01:50] that should be better [21:03:34] ah nice, Ill take a look [21:07:47] good night! [13:51:09] hey [14:43:16] hey [14:59:49] did some more testing with my branch last night [15:00:33] I'm trying to think of a good way to add the ARIAs for parts of missions like TLI [15:00:56] there are some gaps in coverage in LEO [15:02:37] ARIA is tricky [15:02:43] why do they have to move :D [15:09:09] also moved from mission to mission, that's probably the bigger issue [15:10:23] and only active on some revs [15:11:02] they could probably be fixed at the TSP (test support position?) [15:11:49] given that they wouldn't move very much during a pass of the spacecraft [15:12:05] true [15:12:20] not exactly Mach 26 like the CSM [15:12:27] right lol [15:15:22] the ground stations have an "active" variable I think [15:16:40] yes [15:17:46] we could add a page to PA-MFD, set position, enable/disable [15:17:56] something more automated would be nice though [15:22:58] on MCC supported mission it could be done at specific times [15:23:15] but that's not really a good solution [16:12:47] obviously the only solution is to fly them manually then. :) [16:57:23] morning! [17:08:54] hey Mike [17:09:27] what's up? [17:09:44] merging PRs :D [17:09:55] good times :D [17:09:58] I have one with you as a reviewer ;) [17:10:19] https://github.com/orbiternassp/NASSP/pull/820 [17:10:22] I saw, but have been too busy/tired to look at it [17:10:35] will try to get to it in the next day or two [17:10:45] sounds good [17:11:01] I want to code-review myself as well and double-check that all of my Comanche 55 changes are good, and that I didn't miss any [17:12:31] it seemed to work at least, Mr Residuals tested it with a scenario I changed. But there is no feedback that it actually set the right output bit for the right time [14:29:58] hey guys [14:30:17] Space Shuttle Vessel has been released, what a shock, who could have predicted that ;) [14:40:10] hey Niklas [14:41:41] so what is that exactly, a fork from SSUÉ [14:41:49] ?* [14:42:36] yep [14:42:39] SSU basically died [14:42:50] and GLS is continuing on his own basically [14:43:21] at least it's a realistic Shuttle for Orbiter under active development [14:43:45] ah really didnt know it died [14:44:19] people having less time and a few arguments over priorities lead to it, I think [14:46:57] he contacted me about including references to my Shuttle FDO MFD in the manual, so I knew the release was imminent [14:47:12] hey guys [14:47:15] nice to see it release [14:47:47] hey [14:54:26] it's also very nice that it's on GitHub and not SVN/Sourceforge [14:54:34] yeah [14:57:40] the Launch Test scenario, same as the one in SSU, is a STS-101 [14:57:42] launch [14:58:01] I wanted to set up a rendezvous, but it doesn't insert into the proper orbit [14:58:08] SSU also could never do that [14:59:50] well, the ISS is also not in the right orbit I think [15:00:13] maybe I'll make a pull request for the ISS state vector in that scenario :D [15:00:59] hows the launch guidance in SSU/SSV? [15:01:10] too simple [15:01:15] can't insert into a specific orbit [15:01:26] orbital plane I should sy [15:01:28] say* [15:01:30] I Seem to remember it being unable to do lateral guidance [15:01:32] just some simplified calculations with the inclination [15:01:34] yep [15:01:41] ah [15:02:30] I wonder if the real equations are available, like they were for the LVDC? [15:02:37] partially yes [15:02:52] many years ago I used them to code an autopilot for the Delta Glider [15:03:09] but I believe what is available is a bit outdated, early 70s stuff [15:03:12] never flew like that [15:08:22] it's a very clean structure though, the Shuttle ascent guidance [15:08:32] I like it a lot better than the IGM to be honest [15:11:21] on that matter, did we ever get news from that LVDC listing from a while back, I think we were waiting on lawyers approval or something [15:12:48] yes we are waiting, for many years now [15:12:50] no news [15:12:58] damn [16:51:42] morning! [16:51:49] yeah I haven't heard anything for a while [16:59:28] hey Mike [16:59:49] PR Sent, just minor updates to the RTCC Inputs guide [17:08:29] off to work, cya! [17:14:34] hey Mike [17:16:56] I see you can show your cubesat expertise on the Discord :D [17:20:52] Apollo is boring for a day, I'm doing some Shuttle-ing instead [17:23:42] hah not cubesat expertise, just general spacecraft experience [17:24:05] I guess I technically worked on a 12U cubesat for a little bit but it got way too fat to be considered a cubesat before we launched :D [17:25:00] what's the story with SSU? is it abandoned? [17:30:12] I think there were some personality conflicts involved. [17:31:39] somehow they kept breaking the main SVN "branch?" too iirc [17:38:29] i wouldn't be opposed to sharing some systems code (in a GPL2 approved way) with SSV at some point [17:59:00] well my personal view of it was, people who did not have time anymore to contribute much work were at the same time setting unreasonable standards for everyone else [17:59:36] in short, it kind of fell apart. But SSU developers are still active, maybe one or two of them will even contribute to SSV at some point, who knows. Don't think any bridges were burned really. [19:03:56] well that was only my perspective as an outsider. I hope you're right [20:58:56] night! [15:09:32] hey Nik [15:11:44] hey [15:28:21] had a thought about telemetry. what if we implimented a "checkpoint" feature that would pause, save log data and a scenario and then unpause. the scenerio could then have a path to the log. if users don't care about telemetry they would just have live data, no log, and they wouldn't have to wait for long load/save times. [15:31:39] did a checkpoint even save telemetry log data in the real RTCC? [15:31:51] to be fair, I don't know much about the logging features of the RTCC [15:33:13] was logged telemetry data temporarily stored in one of the Large Capacity Storage units? [15:33:48] I thought logging equaled writing to tape in most cases [15:35:11] I thought it went directly from the Intermediate Data Array to the Disks [15:36:23] I believe the tapes were mainly used for getting data into and out of the computer, e.g. delog, ipl, etc [15:37:08] ah right delog [15:37:12] that's something else [15:37:23] I forgot about the disks... [15:37:56] the Disks had a capacity of 233MB per conputer [15:38:05] computer [15:58:40] that is something that would be good to know more about for me [15:58:44] where was what stored [15:59:11] "Data tables are blocks or arrays of data maintained on direct access devices [15:59:12] (2311 disk) in the OS/360 partitioned format" [16:00:37] oh wow, it was dynamic [16:00:54] "he LCS is used as a high-speed dynamically [16:00:55] changing residence device for load modules and data tables that are heavily [16:00:55] used, but cannot be contained in main storage for the duration of the need [16:00:56] for them. A load module or data table will be put on the LCS when it is requested [16:00:57] and is not presently on the LCS. As long as the load module or data table is [16:00:58] frequently used, it will be retained on the LCS; when it appears that the load [16:00:59] module or data table is no longer required on the LCS, it may be replaced with [16:00:59] another load module or data table." [16:01:28] and [16:01:30] "It is possible to identify load modules and data tables with such low response ; [16:01:31] requirements that they need never be placed on the LCS; in other words, residence j [16:01:32] on a direct access device is sufficient. Conversely, some load modules and [16:01:32] data tables are very critical; therefore, these may be permanently "locked" on [16:01:33] the LCS. " [16:01:59] "direct access" are these discs [16:02:04] so the discs are slower than the LCS [16:02:38] and LCS will be slower than the main memory [16:05:10] https://i.imgur.com/jG0xl8w.png [18:26:04] it's a really goes to show how impressive that was in the day, given how much work it would be in 2022 with modern computers and programming languages [18:27:00] even if it is as much a conceptual challenge as a technical one [19:03:23] yeah all the state of the art IBM stuff plus some extras :D [19:46:55] I like the SSV logo. [20:04:53] hi Alex [20:07:06] hey [20:25:58] hey Alex [20:43:31] did someone say "simple AGC" on Discord? :D [20:45:26] must have been slightly outdated information [20:48:33] I think we need to update some parts of the wiki [20:56:04] night! [21:50:36] how's 16 going? [22:25:16] havent launched yet, aiming for the 23rd as I have like 9 days off strating then [22:25:24] starting* [22:26:10] should be able to fly the whole thing within that [15:09:07] good morning [15:13:57] good morning [15:17:42] hey guys [16:19:26] indy91, to continue our discussion from yesterday about checkpoints. checkpoints are an os/360 feature, I'm not 100% certain that they would save telemetry in addition to all the running tasks and their tables, but I do recall listening to the computer supervisor loop for Apollo 11... [16:21:31] ...some time post TLI the MOC crashed and they had to restart. I recall "we've lost about 45 minutes of telemetry". I'll have to listen again see if they mention where the last checkpoint was relative to that [16:31:55] FIDO (and even FLIGHT sometimes or always?) has to approve each checkpoint, so you can find that on multiple loops [16:57:12] morning! [17:01:32] hey Mike! [17:02:07] what's up? [17:30:54] I'm just trying to figure out how to add unnecessary complexity :) [18:18:25] haha, always a battle :D [18:52:12] I think I need Thymo's help on networking API stuff. I am in way over my head. [20:08:20] PR sent [20:08:36] more RTCC MFD Inputs guide work [13:40:38] hey [14:30:48] hey Nik [14:48:01] we're you going to add the mccvessel to the Apollo 12+ launch scenerios, or did you want me to? [14:50:02] oh, I'll do that in a bit [15:24:36] okay cool. didn't want to duplicate efforts [16:19:00] I really like the mission editor from SSV. it's got me thinking about how we might do something like that. [16:26:43] morning! [16:31:27] hey Mike [16:31:36] n7275, is it written in C#? [16:34:06] I fear just keeping up with padloads for all missions is probably as complicated as that mission editor [16:34:43] But I have created a C++ Visual Studio padload generator that is far from complete, but a good basis [16:36:05] the rest of the scenarios is really trivial I think [16:36:12] just the padloads and the LVDC presettings... [16:44:32] adding the MCCs to the launch scenarios, turns out I do not know all the CSM and LM names from memory [16:47:31] plenty of generic ship names in there. Intrepid, Challenger, Endeavour... [16:50:07] two of those are Space Shuttles, too :D [16:50:18] and one Space Shuttle is on a ship called USS Intrepid, so I am counting that, too [16:53:29] fun fact, all major German navy ships are either called after a state or a major city [16:57:07] ah the US Navy is just too large, so while they name their ships like that too, but they have to name some after people and generic ones like "Enterprise" :D [16:57:59] hah yeah, they also reuse the same names over and over again :D [16:58:22] even with aircraft carriers which there have been not a _huge_ amount of, sometimes 3 of them have had the same name [17:00:13] as long as they keep it to one at a time... [17:02:01] there is also a recent trend to name them after presidents [17:02:12] and you had two George Bush being president :D [17:02:38] hahaha good point [17:06:28] almost added a second MCC vessel to the Skylab-2 scenario... [17:10:59] n7275, PR is up [17:14:20] I think today may be the day I finally place the order for the rope driver board :D [17:14:29] doing one final review with my work EE friend this afternoon [17:19:59] is the full, completed rope reader going to be an expensive device? Or does it not matter much compared to the time investment [17:20:25] .in 9 days investigate standby resume bug [17:22:32] it depends on how fancy you want to make it and how much time you're willing to spend building it :D [17:22:56] the fully fancy version is a couple thousand to build up [17:23:39] but if you're not trying to convince museums that you're professional you probably can get away with much cheaper manufacturing techniques haha [17:24:13] I was thinking in terms of the JWST, like "it would be bad if it fails, but now that we have developed it we can make a second one for only 5 billion dollars" :D [17:24:26] hehehehe [17:24:39] Good evening! [17:24:41] it's hard to make a comparison like that since I wasn't paid for this :P [17:24:58] hey Thymo [17:25:05] hey [17:28:02] I'm back home for a couple hours. Spend the week at my girlfriend's place. Now packing my bags for the scouting camp from tomorrow till next friday. [17:28:58] you have not spent much time at home the past couple of months haha [17:30:30] I have not, been having a great time though. Once I'm back next friday I have a couple of days until I start my job on the 1st. Then I can start settling into a regular schedule again. :) [17:44:08] Something caused a merge conflict with ggalfi's PR [17:44:49] https://github.com/orbiternassp/NASSP/pull/811/conflicts [17:45:21] ah that was my LM master alarm button change [17:45:41] CWEA class now doesn't take care of those buttons anymore and doesn't need that Bclick sound [17:45:49] bit of a dumb merge conflict though haha [17:46:32] probably is only a conflict because CWEA and the now not needed mechanical accelerometer were directly next to each other there [17:48:40] maybe I can fix it all without making a mess... [17:51:05] ah, I forgot the mechanical accelerometer is in fact still a thing [17:52:55] I'll just push to his branch again, fixing the simple conflict and the commented lines [17:53:03] and then it gets merged [17:53:16] Cool. Thank you [17:57:17] Thymo, just needs your approval for the commented lines [17:58:23] or can I also somehow resolve it [17:58:53] Your change got dumped into the merge commit. Oh well. [17:59:05] approved [17:59:21] Only if you use admin privileges to overrule my requested changes. [17:59:35] ah yeah, I didn't make it a separate commit [17:59:41] I'll think of that next time [18:00:03] If I request changes at some point I am required to give my approval before GitHub allows it to be merged AFAIK [18:00:13] It's not a big deal. [18:00:46] it's done [18:01:22] time for the bugs we overlooked to come to light :D [18:12:00] This sneakily got merged in [18:12:01] https://github.com/orbiternassp/NASSP/pull/795#event-7224113560 [18:13:44] I was just looking at that actually haha [18:14:02] not quite sure how that works, wasn't that a separate PR? [18:14:14] I wanted to close it or ask if it can be closed... [18:23:39] He created a branch from the branch he opened that PR from. So the commit from that PR was included in the one that was just merged. [18:24:59] Not entirely the way it should be done, he did fix my comment from that PR though. [18:25:09] Everything got reviewed either way. [18:26:10] a few days ago I made a PR to a branch by n7275, which is what his current PR is based on. But this is a different level of PR-ception entirely :D [18:29:55] speaking of which, other than that, is there anything else that needs to be added to mine? I think I'll leave telemetry/uplink dependancy on signal strength for a separate project + ARIA support [18:34:51] I think it's in a good state. I'll give it a last thorough test tomorrow [18:36:20] sounds good. [21:08:11] night! [04:34:16] .tell indy91 goint to push one final little commit that should safeguard against access violations in the unlikely event that somemoe has a scenerio with no mccvessel [10:51:15] hey [11:22:28] hey Matt [11:23:39] I haven't tried it yet, but have you done a launch with your branch? I am curious which tracking stations it would connect to and if there is a signal strength etc. [11:23:54] during the launch I mean [11:37:40] I flew 11 from launch through TLI. If memory serves it starts on Merrit [11:37:55] makes sense, then Bermuda once it has AOS I assume [11:38:46] I believe so [11:43:11] during TLI there is a large gap between Carnarvon and Hawaii [11:45:05] yeah, I guess that's what lead you to think about the ARIAs [11:47:59] the AOS calculations are entirely based on the CSM, right? [11:48:38] so in theory, if CSM and LM were far apart from each other, the active ground station is the one with signal to the CSM anyway [11:55:51] compared to before any new AOS is inhibited during uplinks [11:56:01] shouldn't mess with anything [11:56:13] LOS still behaves like normal [11:56:50] you will just get a delayed AOS message with ground tracking, if the AOS would happen during uplink [12:01:12] hmm [12:01:14] or does it [12:01:23] if (cm->pcm.mcc_size != 0) { break; } [12:01:30] these skip out of the while loop entirely, right? [12:02:10] that means it would also skip the LOS calculation for the following stations [12:02:52] should that maybe be a continue instead? [12:03:10] just a maybe right now, haven't 100% thought it through yet [12:16:28] how far apart do Gumdrop and Spider get? it's ~120nmi right? [12:18:37] about 100 I think [12:19:26] so maybe 25 seconds in orbital travel [12:20:09] not enough to warrent big changes to track CSM and LM separately [12:20:13] maybe at some point [12:20:17] that's rather wide for one antenna [12:21:24] yeah. the Apollo 9 rendezvous is a relatively small portion of the total mission time of all missions [12:32:37] actually, that continue vs. break change would be bad [12:33:00] if LOS are processed as normal it could have LOS with the TransmittingGroundStation [12:33:03] and set it to 0 [12:33:07] which isn't unrealistic [12:33:48] but maybe not what you want there? [12:36:40] which line? [12:37:24] well your uplink check in the ground station AOS/LOS calculations [12:37:26] /Dont switch to a new station if we're transmitting an uplink; [12:38:10] what that does is, should it detect a new AOS, then it skips the entire rest of the AOS/LOS calculations [12:38:15] because it breaks out of the while [12:40:29] hmmmmm [12:41:04] oh in fact it can have the opposite effect of what is desired [12:41:16] uh oh [12:41:17] if the submitting ground station is e.g. x = 2 [12:41:22] and you uplink [12:41:36] and it sees that station with x = 1 has a new AOS [12:41:47] then y might still be 0 [12:41:55] because it didn't get to [12:41:56] if (GroundStations[x].AOS) { y++; } [12:42:06] and then it does [12:42:07] if (y == 0) { [12:42:08] TransmittingGroundStation = 0; [12:42:09] } [12:43:37] I need to do some rethinking here [12:44:02] or re-ordering of some events at least [12:45:59] maybe it does work with continue haha [12:46:08] changing my mind about that once a minute [12:46:40] in doubt, this code is not yet needed as a good signal is not required by the MCC for uplinks [12:47:16] that's the easy way out, get rid of the check [12:47:24] maybe if instead of breaking out of the loop we set an "uplinking" flag at the beginning, and then only AOS the next station if the flag isn't set [12:54:15] is that different to using continue? [13:02:53] hmm [13:36:35] I'll have to look into this a little later [13:48:33] same [15:01:28] morning! [16:05:20] hey Mike [16:17:21] hey [16:52:25] I'm cheating. I'm flying Shuttles instead of Apollo spacecraft. [17:28:47] there are some cool alternate histories in which you can fly both ;) [17:31:34] my computer doesn't like two Orbiters open at once :D [17:33:43] oh I meant in the same scenario [17:33:59] you could do something like this: https://youtu.be/_qixtjMoMUA?t=54 [17:34:07] Shuttle eating a CSM :D [17:34:50] but yeah, nothing that would prevent NASSP and SSU/SSV to run in one simulation [17:35:32] Skylab reboost [17:35:33] hahaha oh dear [17:36:05] support for those 80s moon missions, etc [17:38:25] would a LM ascent stage fit in the shuttle payload bay? [17:42:44] I think so [17:43:03] Google doesn't give me any pics for size comparison, surprisingly [17:44:06] you definitely could put a CSM in there [17:44:11] the dimensions check out [17:44:20] maybe not a fully fueled CSM [17:44:27] but the size and shape are good [17:45:34] I bet you could put the Apollo 7 CSM and also an ascent stage in the payload bay [18:08:23] I need to be a bit better with my timing if I want to test this uplink thing haha [18:12:10] yeah this is the kind of issue I would only see in code, seems like a rare case [18:12:28] meaning Alex would find it in a day in-sim [18:19:07] lol [18:19:40] just got a good test on my Apollo 9 test scenerio [18:20:03] it does delay further acquisitions until the uplink is done [18:20:23] right, that is the intended part I guess [18:20:43] is this with your current PR or did you already make some changes to it? [18:20:49] no changes [18:21:24] my predicted bug is if it finds a new AOS early in the list [18:21:33] and then "break;" and y stays zero [18:21:52] and resets the TransmittingGroundStation [18:22:56] but that is tricky to test for I guess [18:23:19] first one in the list is ANTIGUA [18:23:42] if you are in AOS to any other station, start the uplink and then it has AOS to Antigua [18:23:49] bad things happen I am fairly sure [18:24:36] well [18:24:38] the break occurs before where it sets the AOS flag, or changes the transmitting ground station though. [18:25:11] I think what would happen is, at the new AOS TransmittingGroundStation becomes zero and so you loose all signal [18:25:24] when the uplink is done it would then do AOS with e.g. Antigua [18:25:29] and that becomes the TransmittingGroundStation [18:27:03] the best test for this is probably with Bermuda actually [18:27:20] do an uplink over the AOS, time to so you get AOS with Bermuda during the uplink [18:27:32] do an uplink over the US* [18:27:56] if that's possible... I think there is an overlap [18:28:08] I should be able to with this scenerio [18:29:23] BDA nominal AOS should be at 122:37:48 [18:33:15] you appear to be correct [18:34:37] it waits to AOS the next one, but someone's turning off their transmitter early... [18:36:49] https://xkcd.com/292/ [18:38:24] if that xkcd were correct, I would long be dead [18:39:20] so [18:39:38] the solution with changing the breaks to continues basically means the AOS would be pending [18:40:01] and it would check all the time during uplink and condition correct for AOS to do the AOS processing [18:40:06] I believe that should be fine [18:40:27] it's going to switch immediately when the uplink is done [18:40:45] -0/+1 second [18:40:55] but yes [18:41:27] right, it only executes once per second [18:41:39] you did some changes to that part of the code, what was the problem there? [18:41:50] LastAOSUpdate [18:42:30] initialized at LastAOSUpdate = 2.0; [18:42:42] so it doesn't run it when starting the sim [18:43:07] so that it runs it on the first timestep [18:43:38] ooh right haha [18:43:42] got that the wrong way around [18:43:46] makes sense [18:44:15] don't need to simulate MSFN booting up Windows [18:45:04] (LastAOSUpdate > 1200) [18:46:33] ouch [18:46:53] I wish my computer had high speed restart [18:48:48] I wish my computer had a tape reader [18:48:51] how cool would that be [18:49:06] that would be insanely cool :D [18:49:16] although any housemates might not agree, they are quite loud [18:51:29] "you are going to endure the noise, not because it's easy, but because it's hard" [18:52:33] I have a few C64 tape drives. not quite fast enough to stream our telemetry data onto unfortunately [18:53:49] so continue doesn't quite do what we want... [18:54:55] Orbiter just hangs [18:55:05] oh right lol [18:55:17] while (x < MAX_GROUND_STATION) { [18:55:25] and it does the [18:55:27] x++; [18:55:28] at the bottom [18:55:45] so you would need to also do the x++ before the continue [18:58:39] or i could just goto my way past [18:58:40] [18:58:41] if (y == 0) { [18:58:42] TransmittingGroundStation = 0; [18:58:43] } [18:59:44] my idea was [18:59:48] if ((cm && cm->pcm.mcc_size != 0) || (lm && lm->PCM.mcc_size != 0)) [18:59:49] { [18:59:50] x++; [18:59:50] continue; [18:59:51] } [19:00:15] not sure how a goto helps you there really [19:00:22] yours is better [19:00:24] you would still be skipping any LOS messages [19:03:03] well my solution looks clean, it just needs to work as desired :D [19:04:00] not sure why that needs to be a while for the loop on x [19:04:08] could also be a for loop... probably [19:07:30] if (!uplinking) { [19:07:31] GroundStations[x].AOS = 1; [19:07:32] if (GT_Enabled == true) { [19:07:33] sprintf(buf, "AOS %s", GroundStations[x].Name); [19:07:34] addMessage(buf); [19:07:35] } [19:07:35] [19:07:36] if (GroundStations[x].USBCaps) { [19:07:37] TransmittingGroundStation = x; //only interested in picking a station to tx USB carrier [19:07:38] } [19:07:39] } [19:08:22] why that suddenly haha [19:09:04] specificially the if(!uplinking) part [19:09:31] no need to mess with the loop flow then [19:09:41] could easly be a for loop [19:12:04] true [19:12:26] yeah I guess wrapping the !uplinking around it would also be fine [19:12:51] only one place that is messing with x [19:16:07] that works [19:16:12] Uplink complete! [19:16:15] AOS Bermuda [19:16:35] and signal strength held and switched on AOS [19:20:44] great [19:52:01] the switch to omni delta makes a bit more sense now [19:52:05] during launch [19:52:53] I just flew one again to refresh my memory [20:30:36] because it better points at Bermuda? [20:31:24] yeah, that launch checklist item neetly coincides with the AOS of Bermuda [20:31:56] omni C is good for Grand Bahama [20:33:46] it's also launch azimuth dependent [20:45:49] speaking of uplink complete.... rope reader driver board has been uploaded and is under review [20:49:41] nice! [20:51:18] that's the kind of rope I like getting excited about, not like the kind from the rope factory I used to work at. [20:54:09] hehehe [21:03:00] It's what's inside that counts. In this case 72KB of inner values. [21:09:12] haha [21:09:37] 72kB that we already mostly know. it's the few hundred special values that make all the difference :P [21:20:18] night! [21:27:07] man, I should probably unpause if I ever want to get going here. "what's taking so long little autochecklist? ...oh" [21:36:30] hahahaha [00:02:19] .ask indy91, I occasionally have crashes opening a second RTCCMFD instance. is this a known bug? [09:27:06] hey [10:12:53] good morning! [10:13:18] it's not [10:13:36] that's the External MFD? Or on the 2D panel [10:14:28] I wonder if it's related to a specific MFD page [10:16:02] external. it may be an orbiter thing [10:17:06] sometimes it's an Orbiter thing but something that could be avoided in MFD code, always difficult to tell [10:17:17] have you tried debugging? [10:17:34] might just give you a generic display related dll [10:24:25] unfortunately I can't reproduce it [10:28:44] is it safe to use RTCCMDF on the external MFDs. or should I expect some MPT stuff not to save? [10:35:14] the only MPT related thing it doesn't save is if MPT mode is active or not [10:35:19] the rest is saved in the RTCC class [10:35:22] which is in the MCC vessel [10:37:54] https://drive.google.com/file/d/19C_oz9QXaH9MdGywdjBjh6GLwBF8O7rj/view?usp=sharing [10:38:08] it is very likely that I've done something wrong then [10:40:44] what's the issue? [10:45:27] I'll load the scenario in a second [10:45:30] could also be a bug [10:45:52] I think your specific case with TLI on the MPT is something I have had trouble with [10:54:04] ah, no next station contacts generated? [10:54:06] that's weird [10:56:15] MPT display itself looks good [10:56:21] so I don't think that part failed [10:59:38] ephemeris was created, but it's finding zero acquisitions [11:04:45] yeah no next station. it worked before I saved this though [11:05:26] and in my Apollo 9 HGA test senerio saving worked [11:06:11] next station that is [11:06:55] *scenario, okay time for more coffee here [11:08:03] it's not really a saving/loading issue [11:08:25] there is an issue in the ephemeris interpolation routine [11:08:52] caused by having the TLI on the MPT [11:09:05] I'd doing a bad thing there, I'm directly comparing two double values [11:09:09] while (TE != EPH.table[NV - 1].GMT) [11:09:26] and thanks to floating point they are not 100% identical [11:09:37] oooooh [11:10:00] I need a tolerance there [11:11:10] there is one generic interpolation routine, you have e.g. an ephemeris with X state vectors, you give it the order of interpolation you want and it interpolates a state vector [11:11:33] in your case the ephemeris is free flight, TLI, free flight [11:11:54] during burns the step length is smaller, stores a state vector every 10 seconds [11:12:31] and then there is another routine, "ELVCTR prevents mixing free flight and maneuver vectors during interpolation." [11:13:09] that basically says, in your case, "only from start to TLI ignition" [11:14:15] and it's having some trouble there with the limit set to TLI start, haven't looked at this code in a bit [11:16:24] it's throwing the worst error the interpolation routine has to offer [11:16:30] "Fewer than two vectors available" [11:16:34] difficult to interpolate then :D [11:17:08] well I'l glad I helped find a bug [11:17:14] yes, haha [11:18:51] in the ephemeris storage routine I have a limit of 0.001 seconds, that's the minimum difference between two state vector for which it would store both of them [11:19:13] so the ephemeris will never have state vectors closer than 0.001 seconds to each other [11:19:29] I'll just have to put a tolerance on the double comparison that's lower than that [11:19:37] let's see if that does the trick... [11:23:22] hmm [11:23:29] there must be more than floating point going on [11:23:34] TE = 68382.052882605800 [11:23:38] GMT=68382.053180999996 [11:24:34] if it was 68382.053180999996 vs. 68382.053181, that would be floating point [11:25:27] yeah, those are a bit more than 0.001 apart [11:26:02] I wonder... [11:26:22] loading from the scenario is as if you have a new tracking state vector [11:26:29] and it then re-calculates the TLI ignition time [11:26:46] I wonder if that is re-calculate ignition time versus the one stored in the scenario [11:26:50] re-calculated* [11:27:26] hmm no, by the time it gets to calculating station contacts everything should have been updated [11:30:22] the FDO orbit digitals display appears to work. not sure if that info helps [11:31:00] the current position data is updating? [11:31:36] yes [11:32:50] what is GETCC? [11:33:43] cape crossing [11:33:52] when it crosses the longitude of KSC [11:34:00] that's the definition of the revolution number [11:34:20] it is negative right now [11:34:32] -17:-25:-1 [11:35:23] that is also generated with interpolation [11:35:26] likely the same issue [11:41:50] separate from the ephemeris there is a maneuver times table, with the start/end times of all maneuvers [11:41:54] the mismatch is from there [11:42:04] the variable TE is from the maneuver times table [11:42:13] while it compares to state vector time tags from the ephemeris [11:42:20] but why the difference, not sure yet... [11:46:35] at least it's a good reliable scenario to debug [11:46:44] already spotting one or two more, minor issues [11:59:01] did I just get [un]lucky with the save? I'm supprised no one has had this issue before [12:01:07] not many people use the MPT [12:03:38] and it only happens when you reload with the TLI on the MPT [12:03:58] yeah I just confirmed it, the time difference is due to a re-calculated TLI ignition time [12:04:07] and something that should have gotten updated isn't [12:04:24] it basically ignored the new time when it comes to the state vector given to the TLI simulation [12:04:32] the time tag on that state vector is the old TLI ignition time [12:07:20] https://i.imgur.com/hausqDc.png [12:07:26] specifically, this wasn't done :D [12:07:32] I thought I followed the flowcharts... [12:10:52] I see, my fault. It's annoying that the same time (maneuver ignition time) is stored in multiple places and I used the wrong one for the update... [12:36:00] how many maneuvers would there have normally been post-TLI in the MPT at this point in a real mission? [12:40:10] at least 3 [12:40:27] TLI, then a 0 DV dummy maneuver at the time when the S-IVB starts maneuvering for TD&E [12:40:42] that one is used to calculate the TD&E angles, Alex' input guide has the procedures for that [12:41:00] and then the LM ejection, small DV but crucially changes the MPT vehicle config to CSM+LM and no S-IVB [12:41:11] on Apollo 10 and 11 there would also be the evasive maneuver, so 4 [12:41:23] and when that is done the FIDO can breathe for a moment [12:41:42] and both him and RETRO can start calculation MCCs and abort maneuvers [12:41:47] calculating* [12:41:57] hello next station contacts, welcome back! [12:42:53] yay! [12:46:13] so instead of [12:46:14] while (TE != EPH.table[NV - 1].GMT) [12:46:16] I now have [12:46:21] while (abs (TE - EPH.table[NV - 1].GMT) > 0.000001) [12:46:24] is that a good solution? [12:47:38] there is also a check if NV becomes too high [12:47:44] it can never get stuck in the while loop [12:47:58] in fact that's what happened in your case and caused the error return and interpolation failure [12:48:36] this code is not needed now technically, the bug you had was elsewhere and this code would work again [12:48:44] but I guess comparing doubles directly is a bad idea... [12:49:34] I think that would work [12:52:43] yeah, floating point comparison is a bit of a pain [12:53:00] the MCC uses the MPT for TLI as well, I guess in theory this bug could have happened to people who saved/loading after getting the TLI+90 PAD but before the TLI PAD [12:53:25] oh actually, I can change that now that the TLI PAD calculates accurately without the MPT [12:53:45] better not let the MCC use the MPT, too likely that it breaks some time... [12:54:00] is the TLI+90 an RTCC or a RTACF thing? [12:54:37] RTCC [12:54:59] that's why the FIDO really quickly needs to add all those maneuvers to the MPT after launch [12:55:07] so that the RETRO can calculate the PADs [12:55:39] but RTACF also had the capability to calculate RTE maneuvers [12:56:11] ahh okay [12:56:14] 000:44:00: AST: MPL, vector time 4:06, TIG is 4:14, DV 10k, entry profile 4G, 16h time of landing. AOL, not MPL. [12:56:20] 000:46:10: AST: MPL, vector time 7h, TIG 7:44, 10k, 4G, landing time 25h. [12:56:30] you probably know my next question [12:56:33] that's TLI+90 and TLI+4 [12:56:54] RTACF MFD when? :D [12:57:57] TLI+5* [12:58:04] I have some pieces that only the RTACF could do in the RTCC MFD actually [12:58:14] like the powered descent abort constants calculation [12:58:18] haha well not quite [12:58:37] how do I calculate the TLI+90 abort [12:58:56] I actually quoted the inputs above already :D [12:59:04] that's from my notes listening to the RETRO [12:59:25] oh whoops haha [12:59:32] TLI + 90 would be to the AOL, vector time 4:06, TIG is 4:14, 16h landing time [12:59:45] well in my shorthand consisting mostly of abbreviations :D [13:00:06] but that is all Apollo 11 actually [13:00:45] AST is Abort Scan Table of course [13:00:59] oh one other thing the RTACF could only do, I think [13:01:24] hmm [13:02:24] I thought they got a note on the TLI PAD about an abort right after TLI [13:02:30] maybe the later missions didn't get that [13:03:06] 001:44:30 McCandless: Roger. TLI: 2:35:14; 179, 071, 001, burn time 5:47, 10435.6, 35575. Roll for Sep 357, 107, 041; 301, 287, 319. TLI 10-minute abort pitch, 223. Readback. Over. [13:03:15] TLI 10-minute abort pitch, 223 [13:03:27] the RTACF had a specific method for that [13:03:38] but I'm sure you could still calculate it with the RTCC [13:03:49] just need to go through the whole process with AST and RTE Digitals [13:03:54] just to get that pitch angle [13:07:05] using the MPT you probably want to have the LM ejection on there [13:07:40] but the RTE can deal with it I believe so that it wouldn't use the S-IVB mass [13:42:40] building your branch [13:56:46] that works! [13:57:54] I also tried adding TLI+90 to the AST, and that works as well [14:12:04] stupid little bug, moving TLi ignition by 0.0003 seconds and everything stops working :D [14:22:58] at least we can debug it by just looking at the code, rather than blinking lights and punch cards [15:51:14] morning! [16:00:44] hey Mike [16:03:16] just watched Marc's latest video. [16:22:29] I wonder what kind of horizontal resolution you would need for a good slow scan TV simulation.... [16:30:18] definitely in the "dangerous ideas" category [16:42:00] hahaha [16:42:08] and firmly in the "things I know absolutely nothing about" category :D [16:54:51] n7275, oh god, very dangerous [17:03:02] yeah, there are way better ways to acheve the same effect [17:10:24] indy91 is there any RTCC functionality like the Station Contacts display, but for Omni/HGA during PTC? [17:11:08] not one we have. But I always wondered that, too [17:11:18] a display aiding in selecting the right antenna [17:11:30] that has to involve a certain amount of calculations with attitude [17:11:42] so it's not just a dumb telemetry only display like most of them [17:13:12] oh they using something like that in the restored MOCR [17:13:54] let me find good pics... [17:14:43] https://cdn.arstechnica.net/wp-content/uploads/2019/06/console-row3-wide-procedures.jpg [17:15:47] in the CSM one, it has the letters A to D [17:16:02] there must be a dot on the display showing the current Earth direction or so [17:16:10] and that way you could maybe tell the optimum antenna [17:19:32] ooooooo [17:19:48] I think I've seen that before now that I'm looking at it [17:20:15] me too, but I hadn't thought it through how it would actually work [17:20:38] I wonder if that dotted line on the CSM display is earth position over time or something [17:21:11] Reentry has this display [17:22:21] but my usual sources don't have any additional details about this [17:23:05] I'm not even finding it in the list of displays for Apollo 11 [17:23:14] maybe was added later [17:27:11] this display would likely just make the antennas point at Earth [17:27:14] not a specific station [17:27:42] or not [17:27:45] "TARGET MADS" [17:27:47] Madrid? [17:28:01] and Honeysuckle on the LM one [17:29:37] they did have it on Apollo 13 [17:29:43] it's mentioned in a report [17:30:20] I wonder if there are any clues in the audio during PTC. [17:31:21] well the flight controller looking at it had the right antennas ready all the time for Apollo 13 [17:31:36] maybe earlier missions they just estimate switching times from telemetry imu angles [17:32:22] the Apollo 13 report says [17:32:24] "The LM Look Angle Display (MSK 1475) did not operate according to [17:32:24] requirements submitted prior to Apollo 11. The error is that the [17:32:25] . display does not operate when low bit rate telemetry is being [17:32:25] received." [17:33:05] it's not mentioned yet in the April 1969 RTCC Support Plan with the list of all displays [17:33:21] but maybe they did have it already on 11 [17:33:55] maybe they had the CSM one earlier [17:34:34] neither of them is mentioned in any documents I have, so it's quite likely that they got added at some point in 1969, but when exactly, no idea [17:37:44] but then all my RTCC documents are from early 1969 or earlier... [17:41:30] it would be interesting to see if you could switch antennas at the right time using nothing but our telemetry client. [17:43:50] the calculations will need a state vector [17:44:52] the LM one says "data source MPT" [17:45:30] so maybe the display could run on telemetry state vector, but that would need conversion. MPT probably means an interpolated state vector from the ephemeris [17:45:43] I was thinking of watching V64 for rotation, but I suppose the earth is going to move relative to the spacecraft in more than one axis [17:46:20] *"for one rotation" [17:55:45] I suppose that's probably what the telemetry source mode is doing, but with the RTCC rather than the AGC doing the work [18:00:15] attitude definitely comes from telemetry [18:00:30] the displays show the current REFSMMAT ID, that is then used to convert the attitude to inertial [18:02:42] oh, the Apollo 13 report mentions that there was a bit of difficulty with these displays, because now another flight controller, INCO, needed to communicate with Dynamics in the RTCC [18:02:59] that sounds like something that would happen on the first mission with such a capability [18:03:19] Apollo 13 INCO audio would probably be interesting [19:13:11] hmmmm [19:13:29] so now that the board has been ordered.... it's probably time to start thinking about how I can modify this design to read Block I ropes [19:14:06] I'm pretty confident I can use the driver board as-is for Block I... _maybe_ with some tuning resistor changes, but they might not be necessary [19:19:31] are there any interesting Block I ropes to get? [19:20:18] Sunspot? [19:33:46] Sunspot would be very interesting indeed, but I've never seen a single module of it [19:34:35] I know of Sunrise 69 (which is the Aurora/Sundial equivalent) modules and Jimmie's AS-202 modules [19:35:09] and maybe also Eclipse modules? [19:44:57] oooh right, AS-202 [19:45:11] couldn't quite make that mission work properly with Solarium [20:28:51] I'm getting a bit stuck trying to add the extraction to the MPT [20:29:34] I assume that would be a direct input too? [20:29:57] yeah [20:31:25] oh the input guide by Alex got smaller [20:31:44] that used to be in quite detail in there [20:32:00] I guess he removed it because the TLI PAD is now accurate enough [20:38:58] but the extraction is basically a 3 second burn and it's not External DV but you give it an attitude [20:39:15] and you make it undocking with configuration after undocking being CL [20:40:14] is the 0DV seperation also undocking, but with config C? [20:40:38] no [20:41:01] no need to model it in that detail and, while docking maneuvers are in theory supported, they don't really work yet for us [20:41:50] the 0DV sep maneuver is really just a dummy to get an IMU attitude from the specified LVLH attitude [20:42:20] the extraction is real though [20:42:44] RCS, ATT: Inertial [20:43:01] and then you need to switch over the burn data to the right input method [20:43:16] direct inputs have too many possible variables, doesn't fit in one MED :D [20:43:33] BPA button and type P1 [20:44:22] and then you need to put a MED in [20:44:28] M40,P1,,,3; [20:44:31] for a 3 second burn [20:46:17] okay [20:46:31] I was getting confused by the M40 format [20:49:35] yeah, I didn't want to make that a third page just for direct input so I squeezed it into one button [20:49:42] maybe I should make it separate and easier [20:50:02] oh another simplification, for the extraction they were only interested in getting the right DV [20:50:39] so instead of making that a RCS -X burn with an attitude 180° pitched from separation, they just used the same IMU attitude as the 0DV CSM sep maneuver [20:50:41] and +X [20:59:15] that makes sense [21:06:36] I'd you want, I wouldn't mind adding a some MED format tables to the manual [21:08:20] M62 might be good to have in there [21:10:06] sure, I just got lazy and didn't add enough of them haha [21:11:03] is the TeX on GitHub? [21:12:15] yep [21:12:35] if you have any trouble with it, I can of course add these MEDs myself [21:17:13] night! [14:23:08] hi Jordan [15:18:05] hey Jordan [17:12:23] morning! [18:11:30] hey [18:18:47] hey hey [18:19:21] what's up? [18:22:06] rope driver board has passed review :D [18:22:17] just working out some final BOM things and then they'll start building it up [18:22:45] next month is not unrealistic for first new ropes [18:24:17] that's very impressive [18:24:54] I'll be ready [18:25:02] hehehe [18:25:09] I better start a branch for an updated Apollo 12 scenario soon, with padload [18:25:12] and 13 I guess, too [18:25:20] yeah I'm not sure which of those will come first [18:25:35] Aurora 88 is the most likely first rope, which is not as useful for you as it is for me haha [18:26:07] I like Aurora [18:26:25] for LM131r1 and Comanche 67, it's a matter of scheduling for one collector and a matter of comfort for the other [18:26:30] so it could go either way [18:27:36] running Aurora in the LM was a nice light show, I'll always think fondly of Aurora because of that, even if this is a different version haha [18:28:39] I am so incredibly curious to see how the real Aurora differs from our weird one [18:29:05] e.g. if its gyrocompassing code is going to be more similar to Sundial or Aurora 12 [18:31:07] were those so different from each other? [18:32:35] very much so yes [18:33:09] it's part of the reason why I haven't ever finished the Sundial disassembly haha [18:33:55] Sundial being the outlier to what you would consider "normal" gyrocompassing? Or Aurora 12 [18:36:00] I have no idea! [18:36:10] Aurora 88 will answer that question haha [18:36:23] that is nice! [18:36:43] Aurora 12 matches Sunburst, but that's not surprising since I think our Aurora branched off of Sunburst [18:36:58] ah, I was just typing that question about Sunburst [18:37:04] so it could have been changed in the Sunburst revisions between Aurora 88 and Aurora 12 [18:37:41] oh god, now I remember what we went through with the Block I emulator. Not gyrocompassing directly, but the initial alignment. [18:37:44] I wish we could find some Sundisk modules too.... [18:37:51] hah yes, that was fun :P [18:38:09] I was calculating with octals until I was 99% sure there was a bug :D [18:38:26] hey [18:38:43] hey Alex [18:39:03] yo [18:47:50] Ill have to try the space shuttle soon and learn the FDO MFD [18:48:49] did you ever try the MFD when I first created it 3 years ago? [18:50:07] no I never really got into SSU much to be honest, except for looking around at the code [18:50:26] but I dont think I tried the MFD yet [19:04:40] setting up a good rendezvous plan with it is a challenge, but you are used to my overly user friendly stuff from the RTCC MFD :D [19:06:28] so with the deorbit stuff added, I guess the FDO MFD supports a full mission? [19:07:12] rendezvous mission* [19:07:40] well the deorbit display is a bit like the Abort Scan Table where the proper deorbit targeting would be the RTE Digitals display [19:08:19] very simplified calculations, mostly useful to know on which orbit to land [19:08:29] but the calculated TIG is somewhat usable [19:08:37] right [19:08:43] and then generic DVS [19:09:07] yeah, the PEG-4D targets I posted in the thread are good with the MFD [19:09:16] those target the entry interface [19:11:22] sounds cool, I will definitely give it a go soon...right now though I am going to fly Apollo 16 as I have a few days off finally [19:11:47] going to run through the pre-launch checklist tonight [19:12:41] I might need your help once I get to using the new DKI :D [19:12:56] No-PDI+12 PAD etc [19:14:48] sure [19:18:30] hopefully, when we eventually get the Apollo 16 MOCR audio, I can verify that the way the DKI has to be used for those maneuvers is right [19:18:57] because it does involve a certain amount of trial and error [19:22:36] a constant DVZ component and a boost maneuver in-between are just not features I see in any version of the DKI [19:25:59] although, Apollo 16 doesn't seem to have the boost, at least not for No-PDI1 + 12 [19:26:53] we can refine the procedure when you get there [19:28:25] dont think it has PDI-0 either [19:33:40] maybe the technique is then... [19:33:59] a direct input manuever on MPT, with DV of +100 +0 -50 [19:34:09] then calculate the DKI maneuver right after it [19:34:26] so TIG just after the direct input maneuver [19:34:51] maneuver would have e.g. a DV of +5 [19:35:07] you replace the direct input maneuver with 100+5 = 105 ft/s [19:35:19] re-calculate DKI, see the DV is below 1 ft/s and you are good... or so [19:42:38] hi guys [19:43:46] o/ [19:49:37] indy91, just so I'm 100% certain i understand, the separation attitude for the maneuver comes for where? I found angles in the older version of the input guide, and is it the LVLH or IMU uption? [19:50:26] hey Matt [19:50:41] the sep attitude is in LVLH, which is what the LVDC maneuvers to [19:51:10] when the S-IVB starts maneuver to the TD&E attitude it immediately freezes that attitude inertially [19:51:41] so the RTCC way to get that attitude is to input the time when it starts maneuvering, at TLI cutoff plus 900 seconds [19:51:52] and specify the LVLH attitude there [19:51:56] with the 0 DV, RCS maneuver [19:52:19] and then you can get the IMU attitude for that maneuver on the Detailed Maneuver Table [19:52:51] that will be the IMU attitude that the CSM actually has from the time the S-IVB has finished maneuver to CSM sep [19:53:36] and because extraction attitude is 180° pitched from that, the 3 second RCS burn for LM extraction is also using that IMU attitude [19:54:09] just with the +X RCS thrusters, when it would actually be -X [19:55:25] those LVLH angles are a bit annoying because it uses a different order of angles than the LVDC would. If you could specify the LVLH angles in the LVDC system it would look a bit nicer. [19:56:27] in LVDC coordinates it would just be always 180° roll, either plus or minus 40° yaw (depends on light) and some mission specific pitch angle (also depends on lighting) [19:57:09] but the LVLH angles are the ones the ones from the input guide correct? [19:57:28] yes [19:57:43] okay cool [19:58:30] that's the exact process the FIDOs went through after launch [19:59:04] you think there was plenty of time between launch and TLI to get that all done, think again, it was a lot to do :D [19:59:10] you would think* [19:59:23] I presume those angles come from a LVDC parameter and a coordinate transformation? [20:00:08] yeah... actually, in the old version of the input guide Alex has listed the two version as CSM LVLH and LVDC LVLH [20:00:33] okay that makes now [20:00:43] makes sense now [20:00:48] forgot a word [20:00:52] happens [20:01:00] what is listed there as "CSM LVLH" is in the LVDC presettings we have [20:01:22] And the angles you input into the RTCC are from the FIDO audio [20:01:43] but the numbers agree with the equations from the IBM RTCC documents [20:01:51] as expected give the same inertial attitude [20:02:55] okay. definitely an exercise in "know" vs "understand" for me. [20:03:44] the FIDO had a worksheets with those LVLH numbers on it and it was his job to read them to Dynamics, doesn't require full understanding why it has to be done that way :D [20:05:19] also careful how you enter the numbers, those direct input attitudes are not the usual RPY [20:05:34] but Alex has listed them as PYR, that helps [20:05:45] that's what the M66 MED wants [20:06:43] ah the MED even has a note, "LVLH attitudes are relative to the body". That's why they appear different than the ones in LVDC presettings [20:58:20] night! [22:26:06] AlexB_88 Nik and I were talking about it yesterday, but I think you update to the input guide removed some of this info. Do you think we should add that back, maybe as an appendix? [22:34:55] ah yes, there was the procedure to build the TLI PAD manually using the MPT and various displays like the DMT and checkout monitor [22:35:58] but since the TLI PAD in the PADs section can now calculate an accurate TLI, I decided it was useless to have the whole manual method in there [22:36:35] maybe there was something in there that was still useful? [22:39:53] n7275, here is a screenshot of the removed section: [22:39:57] https://www.dropbox.com/s/jeb5wwrmb1oxgts/Screenshot%202022-08-22%2018.38.48.png?dl=0 [22:51:02] I think a table of those LVLH attitudes would be handy to have [23:00:54] ok I will add the LVLH attitudes back on the next update [23:04:03] can we add maneuvers directly with using only MEDs? [23:06:55] I think most things are done with MEDs "under the hood" so yeah I imagine you can if you know all the codes [23:13:47] it would appear so there is an M66 in PMMMED [23:46:50] that's definitely hard-mode though :) [14:16:31] hey guys [14:36:37] hey [14:58:41] n7275, got a good scenario to test the Apollo 9 HGA test with your branch? [15:01:17] ah, not home right now unfortunately [15:01:39] one of the mission scenarios is really good for it [15:01:45] I thought I had one actually [15:01:49] maybe it's an older one [15:01:55] around 122GET [15:03:52] another interesting case should be after TLI and before reentry, when it gains/looses contact with all those C-Band stations [15:09:20] hey Niklas [15:11:33] hey, on the way to the moon yet? [15:12:26] so while doing the pre-launch checklist with the checklist MFD auto exec mode (im lazy I know), I noticed the SPS thumbwheels are still set to P,Y = 0,0 [15:13:06] I believe they should be set to -0.53, +1.9 [15:13:14] yeah that's wrong, needs to be set to CSM alone trim angles for aborts [15:13:28] the CMC has the proper values loaded [15:14:09] yeah the padloads are right [15:26:11] I think the "before SPS 6" scenerio is the right one [15:27:06] setting up the dap for retro orb rate and flying over the US is fun to watch too [15:30:47] 20 minutes before reentry with Apollo 11, so far it switched from Honeysuckle to Tananarive to Carnarvon somewhat quickly when the last two got into range [15:31:02] and then you use the omnis anyway and switch off the HGA [15:31:24] for those switchovers it was still quite far away from the Earth [15:31:41] don't think the HGA direction changed much [15:32:09] I guess blackout during reentry isn't implemented yet :D [15:34:10] oooo new project idea :) [15:37:35] the RTCC can calculate blackout times and for that it uses a polynomial of velocity vs. height [15:37:50] so input is velocity and then you compared calculated height with actual [15:38:25] but it can of course be calculated in a more sophisticated way [15:38:34] so I keep hearing a "chime" every few minutes on the discord which is getting annoying, anyone know how to stop it? [15:39:33] you mean when there is a new message? [15:39:53] I've muted a few channels that I am not reading [15:39:55] I dont ven know what its for, its not with new messages [15:39:58] even* [15:40:02] it seems random [15:40:09] hmm, I don't get that [15:40:11] and only sounds when the discord is on [15:40:21] it's checking if you are still alive :D [15:41:23] I just tried mute channel [15:41:28] maybe that will do it [15:43:58] I mute all channels. [15:48:56] I was on Carnarvon and then I got LOS Tananarive, Carnarvon (which got me to Honeysuckle) and then quickly LOS Honeysuckle [15:48:59] so now I am on none [15:49:03] I guess I could get on there and stream something at some point again. I have my audio set up again now. [15:50:09] need to check if they put a ARIA between Australian and Hawaii [15:53:23] ah no, it was the USNS Redstone [15:59:57] n7275, I think as long as we have no tracking ships and aircraft, blackout would be boring as it happens without any station in sight anyway [16:00:05] exception being Apollo 7 and 9 of course [16:06:24] I think muting the channel did it [16:06:55] indy91, I am using the GOST to get my SXT stars for the TLI+90 PAD [16:07:23] I did ATT: 1 240 356 001 [16:07:42] SXT: 3:50:0 1 CUR [16:07:56] I haven't looked at the GOST in ages, I need to learn it myself first :D [16:08:01] but I keep getting all zeros and "two stars not available? [16:08:08] not matter what GET I use [16:08:36] no matter* [16:10:07] is that display only available with MED code? [16:10:35] 3229 [16:10:38] 229* [16:10:59] I mean G10 [16:11:42] what are you entering for it to calculate? [16:11:48] I accessed it from the TV guide page [16:12:04] oh I see, internally it uses the MED format [16:12:17] but the buttons on that display work with you having to enter the full MED input [16:12:19] doesnt seem to be any errors on the online monitor [16:16:22] no clue [16:16:34] I can try debugging it with a scenario [16:17:36] oh wow [16:17:43] I think there is a pretty major bug in there [16:18:00] it doesn't even put anything in the state vector [16:18:13] so it's probably a 0,0,0 position vector at the center of the Earth [16:18:44] that must have happened when I changed the ephemeris format [16:20:47] it's a one line fix I think [16:21:05] wanna try it on your end before I go through the whole pull request process before you can get it? [16:21:11] yeah it was not working with pretty much any scenario for me, any attitude input [16:21:20] sure [16:21:24] rtcc.cpp [16:21:34] that way I can finish my TLI+90 PAD :D [16:21:38] line 34527 [16:21:47] does that say "Get ephemerides"? [16:25:03] yes [16:25:15] just above it add [16:25:16] sv = RotateSVToSOI(outtab.SV); [16:25:37] outtab contains the interpolated state vector and further down it is using the state vector "sv" [16:25:47] ok [16:25:50] but nothing got ever written to "sv" :D [16:26:01] that should be it [16:27:02] there is some very similar code about 100 lines up where that is already done, but for the COAS/boresight data [16:28:00] must have gotten lost just for this type of calculation [16:32:09] hmm [16:32:16] still not working for some reason [16:32:47] then I'll have to debug it properly [16:32:55] https://www.dropbox.com/s/g9jgouvz0ktawy2/Apollo%2016%20-%20Launch%200005%200022.scn?dl=0 [16:33:51] in that scenario I used the GOST for my TLI+90 attitude P:240 Y:356 R:001 [16:34:08] the REFSMMAT CUR is set in the RTCC [16:34:18] and it's still the same error? [16:34:30] yeah "no two stars found" [16:34:37] and all zeros for everything [16:34:54] I mean previously it was always occulted because the state vector was literally at the center of the Earth, but now [16:35:11] since I am in earth orbit I kept trying increments of 30 mins for the GET [16:35:27] as I know have the time it would be invalid anyway in orbit [16:35:32] half* [16:35:50] but still no joy [16:37:25] oh, no TLI on the MPT? [16:37:48] well I had one before, when I did the TLI=+90 PAD [16:38:11] would be useful for an attitude at the time of TLI+90 :D [16:38:42] but I guess now the issue is why it didn't find any stars even in Earth orbit [16:45:12] ah yeah, more dumb code [16:45:48] if the first star in the star table is occulted it just gives up [16:46:22] oh, workaround [16:46:27] let it start with star 2 [16:46:30] instead of 1 [16:46:56] ah no, might not work [16:48:19] well, if your attitude is in theory good then trying a few different starting stars might actually work [16:50:48] I can have a fix ready soon [16:55:16] I tried a few different starting stars but not much luck, I guess you have to choose the right one [16:55:21] sounds good no rush [16:56:30] I can give you the data like a CAPCOM ver soon I hope :D [16:56:35] very* [16:59:35] morning! [17:02:13] bug fixed. star 37, 26° trunnion, 5.5° shaft. star 40, 25.4° trunnion, 269.2° shaft. [17:02:16] hey Mike [17:02:54] at least if this display can be believed [17:03:07] that's without TLI on the MPT [17:05:54] thanks [17:06:42] all channels muted on discord and still get that dang pinging sounds arrghh! [17:06:51] https://github.com/orbiternassp/NASSP/pull/829/files [17:08:25] thanks. Im flying TLI but I will test it after TD&E [17:12:44] I need to have a look at font sizes and MFDs [17:12:58] with the External MFD there is exactly one size where the display actually looks right [17:13:06] every other size has letter overlapping lol [17:15:10] Orbiter's MFD scaling is very annoying [17:15:25] right [17:15:31] ok I just tested your changes [17:16:54] looks good [17:17:05] PR approved [17:17:45] done [17:18:26] is the same issue also possible for the BST star? [17:18:55] because its not finding a BST star but I guess there isnt one in the FOV [17:19:34] ah damn, I should have looked if it was similar code [17:19:36] and it is [17:19:58] haha [17:20:11] actually, if I am going to do more work there I will probably combine the two search modes (sextant and boresight) because it's a lot of common code [17:53:42] indy91, now for some positive finds :D [17:54:44] after TLI I did a quick MCC-2 mode 4 TLMCC calculation is showing 5.7 fps [17:55:23] and that is with nothing specified in F23 (LOI GET constraint) and it still gets me an LOI within 1-2 mins of the flight plan [17:55:47] so something went right with the TLI and cutoff logic this time [17:56:00] I think that was an issue in the past if I am not mistaken [17:56:58] it was yes [17:57:03] that sounds pretty good [17:57:32] and TLI pad was quite accurate [17:57:58] DVC overshoot of 10 fps on the EMS at cutoff but I think that is low [17:58:36] I think our TLI PAD has the DV for cutoff [17:58:51] and not total DV [17:59:00] not quite sure what they put on the real TLI PAD actually [17:59:20] so a bit of an overshoot, like an SPS burn, is currently normal [18:00:45] right [18:01:28] oh I think that is wrong actually [18:02:04] in the mission techniques for EPO and TLI it says "DVC is the value set into the EMS DV counter which includes predicted longitudinal DV plus tailoff" [18:06:01] ah interesting [18:06:43] I feel like a bunch of the actual missions got single digit EMS DV left after TLI [18:06:51] so that would make sense [18:08:54] did real MEDs have comma separated fields or were they fixed width? [18:11:21] https://i.imgur.com/uC8Ojan.png [18:11:52] each MED has an example of the format I think [18:12:02] K16,HHH:MM:SS etc [18:14:25] but I know very little how inputting these actually worked [18:33:52] AlexB_88, the EMS was not considered accurate enough to be a good indicator to cut off the engine during TLI [18:34:11] they primarily would use the CMC inertial velocity, P15 or not [18:34:19] then burn time, usually predicted burn time plus 2 seconds [18:34:31] and the next preferred solution was to just burn to depletion [18:35:03] oh [18:35:45] https://i.imgur.com/CuCd0Ih.png [18:36:35] great, it's mission specifc [18:36:43] always love that... [18:36:55] 002:57:35 Scott: [Initially faint.] Okay. We cut-off on a VI of 35,614 [fps]. TFC was plus 02; VG was plus 145; Delta-VC was minus 14.9. [19:01:54] not far from what I got [19:14:49] indy91, any pointers on calculating the "SIVB APS MCC-1"? which I presume is the lunar impact burn [19:15:11] RTCC MFD has the calculation and PAMFD has the uplink method [19:15:16] but it needs an initial guess [19:16:54] from the SCOT I guess [19:16:58] nope [19:17:04] flight evaluation report has a section on it [19:17:58] the planned burn was 150 seconds, 189° pitch, 14° yaw [19:18:32] that should hopefully be good enough for a solution to converge [19:20:28] ok [19:20:31] thanks [19:20:49] Ill have to make a new section for those in the inputs guide [19:21:10] initial guess for all missions [19:28:14] is there a specific lat/long to target? [19:29:56] oh right, you need that, too [19:30:38] -2.3° latitude, -31.7° longitude [19:30:56] also from the flight evaluation report section on lunar impact [19:34:50] ok perfect [21:16:43] night! [14:54:53] hey Alex [15:35:43] hey [15:35:51] just did MCC-2 [16:11:16] nice [16:31:56] I was somehow unaware of the online monitor display until very recently. it has made figureing out what I'm doing wrong much much easier [16:38:39] I made it to about 1 minute before TB6 last night. [17:04:52] you were building the TLI PAD? [17:05:42] yeah I like the online monitor, I have it up most of the time [17:38:53] hey Niklas [17:39:00] hey [17:39:21] Alex, yes, plus the aborts. [17:46:20] hey Niklas [17:46:52] quick Q: does the GOST know if the earth/moon is on the way? [17:46:59] in the way* [17:47:54] yes [17:47:59] checks Earth, Sun, Moon [17:49:13] ok [18:10:19] btw the BST star did work for the flyby pad [18:28:34] yeah it has the same bug, if the first star is occulted then it doesn't even try the others [18:41:05] right [18:41:25] liftoff time update scrubbed [18:41:45] im within 10 seconds or so of the REV 2 crossing GET [18:43:10] MCC-4 at 1 fps is also tentatively scrubbed [18:44:40] how large was MCC-2? [18:46:21] 5.5 fps [18:47:02] so small that its almost stressful to use the SPS :D [18:47:45] haha [18:48:02] enough reserves for some crazy CSM rescues [18:49:41] yeah [22:36:27] Apollo 12 TLI isn't making my antenna feature look good [22:47:26] it should have picked up Goldstone, but instead its very happy to sit on Cape Kennedy [23:29:04] ahh wait [23:29:13] Ascension not Kennedy [23:29:49] and we don't define an antenna for it, so it's just not transmitting any power [23:41:23] that ought to fix it [23:41:37] have a 30ft dish [01:11:01] antenna work doesn't sound easy :D [01:11:22] just had a good LOI on Apollo 16 and im off to bed, night! [13:00:40] good morning [13:25:46] hey Alex [14:36:08] how's the moon? [15:06:39] hey [15:07:04] n7275, what happened to your branch. All commits are from 2 days ago? [15:10:53] and are you sure Ascension is S-Band, I am not seeing that in the MSFN configuration matrix [15:16:44] oh [15:16:55] am I doing the same mistake that was originally done [15:17:18] n7275, grey as usual ;) [15:17:26] just coming up on DOI [15:17:43] hey Niklas [15:18:32] ASC = Ascension (C-band Site) [15:18:45] ACN - Ascension (USB Site) [15:21:41] just slightly confusing :D [15:28:04] morning! [15:29:07] https://www.google.com/maps/place/7%C2%B057'18.2%22S+14%C2%B019'39.3%22W/@-7.9549205,-14.3280049,325m/data=!3m1!1e3!4m5!3m4!1s0x0:0x95edb5c0d7e47838!8m2!3d-7.9550556!4d-14.3275778 [15:29:13] that's the S-band site for sure [15:29:15] hey Mike [15:29:46] I see you have some Comanche 72 realizations [15:30:40] yes, figured I would do some homework to be as prepared for the reconstruction as possible :D [15:30:48] I found two extra-helpful memos [15:30:57] hello [15:31:10] https://www.ibiblio.org/apollo/Documents/COL226.pdf [15:31:30] that's a list of *all* of the changes in it, including the ACBs which the FSRR slides don't mention [15:31:40] https://www.google.com/maps/place/7%C2%B058'21.7%22S+14%C2%B024'05.8%22W/@-7.9726986,-14.4021673,287m/data=!3m2!1e3!4b1!4m5!3m4!1s0x0:0x9d4ba9a82fcd76ab!8m2!3d-7.9727!4d-14.4016 [15:31:52] found a document that says the C-band antenna is/was there [15:31:59] different place on the island haha [15:32:34] and this Artemis memo goes into detail on how each of the Comanche 72 changes was integrated into Artemis: https://www.ibiblio.org/apollo/Documents/ColossusMemo250.pdf [15:33:04] I rebased upstream when you pushed your RTCC update [15:34:35] was actually just doubting myself this morning that I got the right one [15:36:46] ah we do have both stations [15:36:48] but the code is wrong [15:36:58] one has ASC, the other has ACN [15:38:43] and I am not sure about the coordinates haha [15:40:13] thewonderidiot, that sounds potentially useful, provided we won't get the Comanche 72 module with the specific changes [15:40:57] yeah. the module we get will have some but definitely not all of these changes [15:42:32] conic subroutine, hmm, always fun for me to match that code in the GSOP [15:47:23] GroundStations 2 and 35 are all kinds of messed up. it's like someone badly xor-ed their capabilities... [15:53:19] I'm sure the others are all fine with no errors [15:53:25] ... [16:02:36] just have to go through all of them, what's the problem? :D [16:03:31] I mean, those two are probably a bit of a special case. It happens to be two entirely different stations on one island [16:03:41] one NASA, one DOD [16:03:55] in other cases it's just different antennas, but the same station [16:13:46] that one's an easy change. I can fix it tonight [16:14:27] at the very least I can make sure that if a station has usbcaps then it should have some kind of antenna...because that's what my code uses [16:17:55] antenna sounds useful [16:25:37] love the 1st orbit after DOI, descending over the hills [16:25:51] as Gene Cernan said “We Is Down Among ‘Em!” [16:27:56] are you doing the mission by the flight plan or simulating the delayed landing? [16:29:26] by the flight plan [19:16:22] indy91, TLAND used by the PDI PAD, is that just so the calculation calculates the PAD for the correct orbit? [19:17:02] or does it also affect the TIG as well? say if TLAND is off by a few seconds/minutes? [19:17:35] PDI PAD runs the same as the P63 ignition algorithm. So it needs an initial guess and will then converge on the right TIG [19:17:44] same calculation* [19:17:48] ah ok [19:18:01] if it's off by a few seconds it will find the same TIG [19:18:07] off by a few minutes, might start failing [19:18:12] reason I ask is because I did an LDP calculation for DOI trim [19:18:15] off by 2 hours, finds the next rev [19:18:27] and its 0.4 fps so I wont burn it [19:18:33] but it did update the TLAND [19:18:38] how much? [19:18:48] 20 seconds or so I think [19:18:56] that's fine [19:19:00] it's more like an initial guess [19:19:06] and not a fixed, desired time of landing [19:19:28] you can uplink that time [19:19:48] but if the update is small, P63 will have no trouble using the original time [19:20:12] a bit of an exception is Apollo 17, with its different trajectory (perilune not at PDI but quite a bit later) [19:20:30] that needs a fairly close TLAND in the computer to converge [19:20:46] I think usually it works for like +/- 10 minutes, maybe slightly less [19:20:59] on my first Apollo 17 flight it failed [19:21:12] I think my orbit was late by 2-3 minutes [19:21:26] so I just needed a better TLAND for it to converge [19:29:47] my landing is about 1 minute off from the flightplan [19:30:02] so should be good without a new TLAND I think [20:04:34] night! [20:20:15] same for me [12:17:56] good morning [12:21:37] I have an additional commit that I forgot to push last night [12:22:21] I should be checking for the correct antennae with & not == [12:30:02] hey [12:32:12] ah rigt [12:32:14] right* [12:35:23] I guess we don't have any site with multiples antennas [12:35:28] but & is better [12:38:04] it's been a month since UHCL wanted me to send some scans within 10 business days [12:38:13] wanted to send me* [12:54:50] maybe they count business days differently down in Texas [12:56:22] oops [12:56:49] good morning [13:13:16] hey Alex [13:19:27] hey [14:11:39] indy91, what is the data source (the real one) of the "DC" vector. I presume s-band ranging/tracking? [14:14:12] yes [14:14:17] DC is Differential Correction [14:14:56] that's the process of taking lots of tracking measurements (range and direction) over a period of hours and then process them to get the most accurate state vector [14:15:40] once that is done the trajectory specialist moves the DC vector to the usable vector table and tells FIDO that he can use it now [14:16:00] what I have not implemented on that vector panel summary yet is high speed radar state vectors [14:16:30] that is done during a burn like TLI and processing automatically some real-time radar data to get a ground tracking burnout state vector [14:16:39] but that SV wasn't very accurate usually [14:41:18] with the "uplink in LOS" option in RTCC MFD enabled, is that dependant on the S BAND signal? [14:42:25] or does it use its own independent logic to determine LOD? [14:42:30] LOS* [14:43:06] oh that's a very old feature, probably not consistently used in the MFD [14:43:16] but it checks if the Moon is in the way [14:43:33] ah [14:44:31] or not haha [14:45:10] checks line of sight to an internal list of RTCC MFD ground stations [14:45:13] no Moon checks [14:46:36] I could probably fix that [14:47:21] so pardon my ignorance, but does the real thing need to register an antenna signal (ie. S BAND ANT signal strength meter) for an uplink to work, or is it through a separate channel? [14:49:29] n7275, if anything I'll remove this RTCC MFD only feature and we start requiring a signal in MCC code [14:49:53] the signal strength, iirc, represents automatic gain control voltage on the incoming s-band carrier [14:50:41] the noise floor is around or a little below -130dBm [14:50:52] yeah I think if it could be tied in with the new MCC antenna features would be ideal [14:51:36] with maybe the option of "uplink in LOS" being a checkbox in the NASSP launchpad settings [14:51:39] I think the bit error rate for PSK is like 1 in 1E6 at 12 dB SNR so like -122dB [14:51:42] m [14:51:49] yes [14:51:52] good idea [16:45:22] at some point I should probably also calculate usb and vhf signal strength that the ground stations receive back from the spacecraft [17:15:07] do our uplinks have any error protection bits? I'm not familiar enough with real/virtualagc distinctions [17:21:33] no idea [17:48:36] n7275, I fixed a few minor things, among them the build warning you added a while back haha [17:48:39] https://github.com/orbiternassp/NASSP/pull/832 [17:57:00] lol [17:57:30] to be fair though, I did fix that in a pull request that has been open since November... [17:58:57] ouch [17:59:09] what was the deal with that PR anyway. Why is it not merged yet? I forgot [18:00:38] it breaks all the systems in saved scenarios [18:01:10] I changed the specific heat model so there are different values for liquid and gas [18:02:20] it has been thuroughly tested, I flew 10 with it, and Ryan flew 16 and 17. but we were going to implement some kind of version check before we merged it [18:04:17] version checking to do what? [18:04:45] warn users about outdated scenarios [18:16:34] which I agree with. [18:27:18] if that is all then I would say, let's make a forum post and get it over with very soon [18:36:03] I'll have no excuse not to resume work on my fuel cell project :) [18:37:32] yeah I am sorry, I didn't know this was basically done and just required some decisions and nothing else [18:40:38] well I think there are some very valid concerns about breaking scenerios...on the other hand, I'm not planning any major systems updates for a while [19:06:56] morning! [19:08:52] Hey! [19:10:04] what's up? [19:10:43] Came back from camping today. I'm exhausted but it was a ton of fun. [19:10:57] nice :) [19:11:37] That was the last vacation for a while. Got a couple of days to relax then it's time to start the 40hr grind. [19:13:12] oh man oh man [19:13:15] time to be full time adult :P [19:40:39] hey Mike, Thymo [19:43:43] yo [19:46:07] I almost forgot how much I enjoyed doing these reconstructions :D [19:46:21] ....not that the reconstruction is really going yet. but this one is going to be very interesting [20:38:21] thewonderidiot, you might know, does virtualagc accept any kind of error correction in the way uplinked words are accepted? [23:26:22] or an I just misunderstand how the up data stuff works [23:26:57] s/misunderstand/misunderstanding [23:42:42] it looks like our PCM class writes to an erasable and than raises an interrupt [03:14:02] oh [03:14:21] it's literally the UPRUPT routine that does the error checking