[12:36:37] NASSP Logging has been started by n7275 [12:36:39] morning Ryan [12:38:51] good morning [13:46:21] hey [13:52:53] hey Alex [13:53:07] good morning [13:54:13] well I haven't tested it yet [13:54:49] I guess don't have to if you do it lol [13:55:20] you just need to start with a scenario that is before 192:20, the time of the HGA test REFSMMAT uplink [13:58:05] well I give it one small test if it even works at all [13:58:18] and as a check for the AOS time it comes up with [13:58:37] should that time be displayed? [13:58:44] That is when 0° roll angle would be valid [13:58:53] good time ot start the orb rate roll [13:58:58] to* [14:02:48] Yeah I think AOS and LOS Carnarvon and Hawaii should be displayed [14:02:58] oh Hawaii too [14:03:00] no problem [14:03:22] Yeah, the test was to see what the antenna did between the LOS and next AOS in REACQ mode [14:03:36] to see if it would reacquire on its own [14:04:02] obviously, we cant sim that yet but its certainly a possibility in the future [14:04:21] I think I have all the new T aligns in as well as the placeholder for the update [14:05:07] I think 192:25 works the best right now [14:05:33] But lets try 192:20 first [14:10:59] 192:25 would be without ground contact in the flight plan [14:11:29] Ah good catch [14:12:19] even though both we and the real mission were a bit later than the flight plan I think [14:13:55] Yeah, if it helps, the actual Carnarvon pass for the HGA test was at 193:06 [14:14:12] In my current mission, my pass is 192:57 [14:14:26] so I am 9 minutes ahead of actual [14:15:06] but I think I am close to the FP [14:15:32] Carnarvon pass they used for the HGA tests was 192:50 on the FP [14:15:38] https://i.imgur.com/2fqvo2J.png [14:15:59] I like it [14:16:36] I have the checklist ready to test the new times, including the extra T-Aligns [14:16:58] I figure I can just leave those written in there instead of uplinking them in a pad [14:17:14] also that SV update at 193h needs to be moved [14:17:23] not sure exactly what time [14:17:55] flight plan has a pass over the USNS Huntsville in between Carnarvon and Hawaii [14:18:15] the new order in the MCC is [14:18:27] 192:20h HGA Test REFSMMAT [14:18:34] 196:45h Block Data 20 [14:18:46] 198:30h State vector (previously at 193h) [14:19:00] and then 209h something in the next day [14:19:09] so SV update moved, HGA Test REFSMMAT inserted [14:19:59] if you like those times I will commit and push the stuff [14:21:25] let me check them and make the changes in the checklist file [14:23:55] pretty much finished the left side panels, now starting on the right [14:24:53] my CMVC branch https://github.com/jalexb88/NASSP/tree/CMVC has been updated if anyone wants to test it [14:25:09] indy91 times look good [14:27:32] AlexB_88, awesome. The process still seems quite manual labor intensive. [14:28:09] its much better then it used to be though, thanks to the work you did on the structure of it [14:28:28] But all the numbers are there now if we ever create a panel class that can handle everything [14:28:38] no more need to define every single animation separately [14:28:44] yeah [14:29:34] hopefully this doesn't lead to some bottleneck soon where the performance gets worse with every switch [14:29:43] the 2D panel suffers from something like that [14:30:55] I dont think it will [14:31:32] ready for the push [14:31:56] having used the LM VC a bit, there is two issues I have right now [14:32:18] I'm pretty sure the FDAI rate needles are not scaled correctly [14:32:21] same in the CSM [14:32:27] or mostly in the CSM is where I saw this [14:32:42] they don't quite show the same value as in the 2D panel [14:33:12] and the other one is three position switches. They work differently in 2D vs 3D. No problem if we fully move to 3D, but right now it's quite confusing [14:33:23] right click vs. left click [14:34:21] I think its the bmp redrawing that really killed performance in the 2D panel, as it is done for everything. In the VC there is very little of that, everything else is animation [14:34:33] right [14:34:47] the CSM FDAI rate needles are still on my list to fix [14:35:45] I think what is also confusing is that in 2-position switches, you only use the left click, while 3-pos are the left and right click [14:35:46] I still want to improve that for the 2D panel [14:36:27] with the VCs getting more complete the motivation for that is not getting better though [14:36:47] my plan is to finish the VC within a few months [14:36:52] both VCs [14:37:30] rcflyinghokie, I pushed it [14:37:51] thanks [14:38:27] the VC is still doing bitmap redraws though, right? [14:38:34] just not for all those switches [14:38:36] only for the displays [14:38:55] the meters are animated or redrawn? [14:40:03] there are 34 bmp redraws as of now in the CSM, wont be much more at finish [14:40:06] animated [14:40:28] yeah that's not too much [14:40:45] and we can and probably should make those animations as well [14:41:11] nearly everything can be done with meshes [14:41:20] I think [14:42:47] yeah [14:44:18] I already made everything that is possible to animate and those 34 are things like DSKY display, master alarm, digits etc [14:44:27] I think its fine like that honestly [14:45:03] yeah [14:45:40] we'll see where it ends up performance wise [14:45:48] oh its fine [14:45:55] its DDS in the VC [14:47:00] with the whole CSM main panel and left side completed I still get 144 fps maxed out with time accel [14:48:03] yeah it's been smooth in both CSM and LM [14:48:57] anything that gives the GPU more tasks previously done by the CPU will do that [14:52:54] one thing I was thinking for the VC is making the left-click/right-click more consistent with eachother [14:53:14] between 2-pos and 3-pos switches I mean [14:53:38] right now the 2-pos does not use the right-click at all [14:54:05] just left click to cycle states [14:54:14] yeah [14:54:28] one problem with the right click is moving around in the VC [14:54:35] but maybe it would be better to use left/right click with those too [14:55:05] you hold the right mouse button and move the mouse [14:55:09] to move [14:55:16] right, you have to be careful with the clcik [14:55:19] yep [14:55:41] how does e.g. DCS solve that? Haven't played in a while... [14:58:05] I have but in VR so not much help with that :D [14:58:59] you can actually differentiate between button clicked and button held [15:00:15] hmm [15:01:14] but it will probably generate both mouse events if you hold it [15:01:46] you can't easily have a check to prevent a mouse click event if you hold the mouse button [15:02:02] I think [15:06:36] rcflyinghokie, I tried a little bit to find out why we got those coarse align errors. All I have found so far is that it might be related to the CMC still wanting to drive the optics. [15:06:56] and if you let it (optics zero off and optics mode CMC) then I get the problem [15:07:11] but I can't say for sure yet if that's reliably the case [15:07:55] hmmm yeah its possible [15:08:41] it can't suddenly be a IMU/ICDU issue [15:08:54] that has worked for more than 10 years without a problem [15:09:21] either it's some recent-ish I/O change we did, whatever that may be [15:09:26] or we use Colossus wrong [15:09:42] I haven't really figured out how to make it stop drive the optics [15:09:51] not sure what routine is running that is doing that [15:10:05] it will simply drive the optics to the last desired position [15:10:21] doing another P52 option 3 might fix that though [15:10:43] maybe if you unsafely exit P52 something like this could happen [15:15:31] it does look like it's finishing the coarse align [15:15:50] but then when it checks if it's at the desired spot within 2° it seems a problem [15:16:00] desired attitude* [15:16:03] sees* [15:19:25] I have seen a lot of it driving the optics after P52 [15:19:38] kind of just ignored it [15:20:18] oh also, for the s065 updates, looks like there is a spot for t align, were those supposed to be for the P52? [15:20:32] it does say if req [15:21:50] yes, those are for P52 option 2 [15:29:38] morning! [15:30:42] so the update I get from MCC has them all balls [15:30:56] are they supposed to be populated? [15:31:11] morning Mike [15:31:16] hey [15:31:29] which one? [15:31:30] which GET [15:32:40] T ALIGN in the S065 update I get at 189:50 [15:33:02] hmm, I think I didn't add any T Align calculation for those PADs [15:33:13] might be correct, not sure [15:33:21] ok [15:33:29] I either was lazy or saw in the transcript that they weren't getting T-Aligns [15:33:35] I will say the timing on the north mexico one wasperfect [15:33:52] and thats with that T align given with the SV update [15:34:11] ordeal is dead nuts on hitting enter on orb rate at that GET [15:34:23] good to hear [15:35:22] this optics code in T4RUPT is not easy to figure out... [15:36:21] and it doesn't really make sense to me that some optics code can screw up an IMU coarse align [15:38:54] oh, back on the S065, when the 191:30 update comes, is that based on the spacecrafts current REFSMMAT? [15:39:34] or the T align one given back at at 187:30 [15:40:38] yeah I think it's always the current alignment [15:41:33] ok [15:41:44] then it should work out as I have those updated T aligns prior [15:48:32] 20 mins into the DAP orb rate, its still dead nuts [15:57:12] thewonderidiot, Ryan and I separately got a coarse alignment issue in the CSM. During P52 option 1 when driving the IMU to the new attitude. 211 and 217 program alarms. [15:57:21] don't think I ever had that before [15:58:44] hmm [15:58:46] which program? [15:58:55] or rope rather [15:59:01] Colossus 249 [15:59:38] oh those are interesting alarms [15:59:46] just got it again [15:59:57] doing my next P52 option 2 [16:00:38] so weird that we are suddenly getting that [16:00:49] I can't think of any recent change that would be related [16:00:54] https://www.dropbox.com/s/ihr945glj3l8vke/Apollo%209%20MCC%20-%20S065%20211_217.scn?dl=0 [16:01:01] saved right after checking v5n9 [16:01:05] if it helps [16:01:21] just started a P52 option 2 with 192h as the t align [16:01:39] gave me the angles, and when I hit PRO to coarse align it throws those two together [16:02:42] and you have optics zero mode off and optics mode CMC [16:02:58] yep [16:03:03] that seems to be a factor [16:03:07] everything on the panel is in the same state [16:03:09] however that works [16:03:25] so maybe that scn can help look for clues [16:05:43] not sure if this is related, but I had another accidental time-aceleration related program alarm last night. just a single one, but it was a 211 [16:06:48] maybe just random register stuff, but thought I should share [16:08:37] and thats in Apollo 7, correct? [16:10:22] yes [16:11:17] we're using 237 on that one iirc [16:11:23] yeah [16:12:09] did any of the agcio branch stuff get merged? [16:13:06] no [16:16:10] I wasn't even in P52 when it happened, so probably not a real alarm. [16:19:51] yeah [16:19:56] unless you ran into gimbal lock [16:20:02] that also causes a coarse align :D [16:22:53] ahh, no, thankfully [16:25:09] about your PR [16:25:27] the only thing I haven't tried yet is a bit of long time coasting, letting it build up clogging [16:25:38] so after the coarse align error, the IMU is not in the correct spot, its close, but certainly off [16:25:52] yep, that was my experience as well [16:26:01] ok glad we are getting similar results] [16:26:16] it's like it stops the coarse align just a bit before getting to the right attitude [16:26:24] or overshooting it, haven't checked [16:26:58] if we were using the ICDU implementation I would expect some issues like this [16:27:02] but it hasn't been changed [16:27:33] last summer we started using the OCDUs though [16:27:39] my N93 angles are -00015 +06323 +00034 [16:27:43] maybe they are doing something bad [16:27:50] yeah, that's what I had as well [16:27:54] just one axis being off [16:27:55] so 2 of the 3 axes got where they needed to be [16:29:36] after torquing and running a star check it looks good [16:30:06] it feels like our OCDUs are using a wrong counter [16:30:14] or influencing the coarse align in some way [16:30:48] that would explain it [16:34:37] n7275, your code says clogging can reduce voltage by 5V in one day. I'm getting lower voltages than before, FC3 has a bit below 28V with 40 Amps or so. 5V lower would make a big difference. Where did you find that number for the clogging? [16:38:39] I will have to look into which document that came from. it does seem rather high. [16:38:58] I will compare against the databook graphs as well [16:43:04] I distinctly recall reading that somewhere. this is why I'm trying to add more reference and citations to my comments [16:43:36] yeah I should do that more as well [16:44:11] with RTCC memos [16:53:57] I'm switching to the NASSP build where this Apollo 9 SPS-7 scenario was created [16:54:10] 3 years ago, feels weird using that version [16:54:46] I want to see if I also get the program alarms there [16:54:51] Good idea [16:55:02] On the second S065 pass [16:55:08] 4.1-33.1 and 4.1-33.2 look like the graphs I need. will throw them into webplotdigitizer later [16:55:16] position looks great, orientation dead on [16:55:53] didn't get the alarm [16:55:58] using the transcript T align and the subsequent S065 calculation/update [16:55:59] oh [16:56:01] pretty sure I did everything the same way [16:56:17] but then it might depend on the specific attitude [16:56:31] so I'll try it a few times [16:56:40] this was when we only had one optics switch [16:56:41] I have a preferred and another nominal coming up I will report if they set off the alarm [16:56:53] but I really don't think it's a problem with that, input bits looked good [16:57:59] did you zero and off before calling P52? [16:58:19] yes [16:58:20] I forgot and zeroed after calling it [16:58:33] but before selecting an option [16:59:23] right [16:59:25] I'll try that [16:59:35] just to see if I can at all trigger the issue in this old build [17:01:17] oh [17:01:27] it happened [17:01:41] so not an NASSP bug. Or at least not one that got added in the last 3 years [17:02:57] interesting [17:03:08] but you said you got it even though you zeroed before calling P52? [17:04:01] I think so. On previous attempts [17:04:12] it seems to depend on attitude [17:04:25] this was the out-of-plane REFSMMAT [17:04:34] so I have to yaw a bunch in the scenario [17:04:35] and roll [17:04:55] on the attempt where I didn't get the alarms I was at nearly 60° yaw [17:05:02] but it more reliably happens at 45° [17:05:14] it seems [17:05:45] so it has to be a mixture of how we use Colossus and maybe a bit of early Colossus buggines [17:06:12] or some IMU issue that suddenly comes up, having hidden for 10+ years [17:07:06] maybe early Colossus has some issue where it can't use all five error counters at once [17:07:29] would be difficult to find any documentation about this [17:10:05] mine was an option 2 so very much in plane [17:11:12] indy91, I made some changes to TwoPositionSwitch that I think will be for the better [17:11:20] TwoPositionSwitch::DoCheckMouseClickVC [17:11:40] it now uses left and right mouse clicks [17:12:10] to align with the way ThreePositionSwitch works in the VC [17:12:16] so that it is consistent [17:12:52] so left click to for TOGGLESWITCH_UP and right click for TOGGLESWITCH_DOWN [17:13:03] and of course depending on the sideways flag [17:14:00] https://www.dropbox.com/s/nnuaqrp3f1varn7/Screenshot%202021-03-16%2013.13.49.png?dl=0 [17:14:06] the old way is commented just above [17:14:17] I just tested this and it works quite well I think [17:20:06] rcflyinghokie, I guess that means the issue is more how much the IMU has to be rotated and not specifically where to. [17:20:57] interesting [17:21:01] AlexB_88, I like that better. But probably even more confusing now to switch between 2D and 3D [17:21:16] right [17:22:52] however at some point soon we'll be able to fly the entire mission from the 3D panel, so if one will not be required to "switch back and forth" to operate things [17:23:05] so one will not be required* [17:24:42] yeah [17:24:49] ie. if someone wants to fly the whole mission from only the 3D panel or only the 2D panel, it will be possible, so I think any inconsistencies between the 2 should not be too bad [17:25:03] the important thing being consistency within each one [17:25:09] if that makes sense lol [17:25:29] but of course in the long run well probably get rid of the 2D panel anyhow [17:30:08] yeah I think it's a good change [17:31:58] ok [17:49:36] there's good info on the effect of oxygen purity on purge interval [17:52:30] shouldn't be too much more than 1V per day at a purity of 99.97% [18:45:53] indy91, so I guess the maneuvering during the S065s changes the AOS/LOS times? [18:46:15] I just did a recompute using RTCC MFD at 192:50 and I am over a minute different [18:46:46] maybe that's two different methods to calculate those times [18:46:53] 192:57:04 on RTCC and 192:58:12 on MCC from the uplink time [18:47:29] MCC uses the function FindRadarAOSLOS [18:47:37] AOS is when elevation angle is 5° [18:47:47] which RTCC MFD page is that? [18:47:52] map update [18:48:04] and it coincides with when I get the "AOS" message perfectly [18:48:29] If I REACQ on the RTCC time, my HGA tracks [18:48:36] if I use the MCC time, no joy and no signal [18:49:18] https://www.dropbox.com/s/7chtf577fcrysrl/Apollo%209%20MCC%20-%20HGA%20Tests%200001.scn?dl=0 [18:49:23] if you wish to experiement [18:49:37] just waiting on the enter at AOS and then switch to REACQ [18:51:11] no need, I know why there is a difference [18:51:32] nice code duplicates... [18:51:41] but the RTCC MFD will have AOS as 0° elevation angle [18:51:42] haha oh [18:51:56] while the MCC uses a different calculation method and uses 5° for AOS [18:52:19] that is the PAD that comes along with the REFSMMAT [18:52:26] AOS messages use which method... [18:52:29] probably yet another one [18:52:49] Hmm so REACQ drives my HGA to almost -90 in pitch and 250 or so in yaw [18:53:09] I bet AOS messages use the same code as RTCC given the timing [18:53:58] yeah, looks like it's also when the CSM crosses the horizon [18:54:52] when the HGA starts tracking, that is the earlier AOS but still 0° roll, right? [18:55:53] REFSMMAT gets calculated with the later time, so that earlier AOS will not have the CSM exactly aligned the with local vertical, but the HGA pointing more down [18:55:57] probably why it works [18:56:10] ahh [18:56:25] so which time should we use? [18:56:46] if I run it as is, and use the MCC time, REACQ doesnt do anything [18:57:00] unless I increase Yaw [18:57:06] (HGA yaw) [18:57:18] no, decrease pitch [18:57:20] yeah [18:57:30] so many things moving in space lol [18:59:23] or use a different roll [18:59:26] IMU [19:00:35] so the usual MCC displays for station acquisition are calculated with 0° [19:00:39] elevation angle [19:00:44] so actual horizon crossing times [19:01:03] where I got the 5° from is the document with details about calculating the Apollo 9 rendezvous [19:01:09] it mentions "5° AOS" a bunch of times [19:01:57] for the CSM? [19:02:53] CSI is placed at 5° AOS of the Tananarive pass [19:03:06] and also I just realized that message only has Carnarvon, not Hawaii times [19:03:25] which message? [19:04:16] the one that comes with the HGA uplink [19:04:42] uhh [19:05:05] how can that be, I even showed you the screenshot... [19:05:28] https://www.dropbox.com/s/7dchov42kwqj3d0/Screenshot%202021-03-16%20150510.jpg?dl=0 [19:05:32] I just realized it lol [19:05:41] it was after a save load though.. [19:05:48] ah potentially [19:05:50] maybe something got screwed up? [19:05:59] you do have my scn right by this time [19:06:00] that is the "generic" PAD [19:06:10] possible that it doesn't like the next line [19:06:16] the \n command [19:07:21] I should probably change how the generic PAD works [19:07:34] but let me re-generate the PAD [19:07:42] maybe the calculation failed [19:08:14] Also, I see the actual antenna positioning was +45, 240 at LOS CRO, so the yaw looks right at least lol [19:08:22] ah the well programmed Checklist MFD strikes again [19:08:28] I get a CTD in your scenario [19:08:32] or is close, obviously we are pointing to the earth not a station [19:08:34] because of updated checklists [19:08:35] uhh [19:08:39] one sec [19:08:44] panel 8 almost done [19:08:48] I can just delete it [19:08:53] the checklist section [19:08:55] ok [19:09:02] panel 5* [19:09:05] I can send it to you as well if you need it [19:09:38] AlexB_88 awesome, so many breakers lol [19:10:26] rcflyinghokie, if I reset the MCC state it comes up with Hawaii times [19:10:31] and now if I close the scenario... [19:10:38] so maybe a save/load thing [19:11:00] Hawaii times gone [19:11:06] ah [19:11:19] yeah it doesn't properly save it, as the Hawaii times are in a second line [19:11:48] I can change it to one line as a short term fix [19:12:36] yeah I see no issues with that [19:13:03] long term fix is a bit more complicated, but shouldn't take too much time [19:13:10] n7275 what was the prognosis on getting tracking stations as opposed to just looking at earth? [19:13:20] This situation would be a wonderful test case [19:15:25] nice GDC gimbal lock btw in your scenario [19:17:05] haha yeah I wasnt sure if they bothered with a GDC align [19:17:16] giving that secant amplifier a good test. The one that calculates 1/cos(yaw) in an analog way [19:17:17] since they came back out of plane after [19:17:44] Ehh they probably did align it [19:17:49] yeah [19:18:00] rcflyinghokie, shouldn't be too hard. after we get my fuel cell project merged I can work on it [19:18:20] ah right, on screen annotations have a size limit. It automatically put the Hawaii LOS time on the next line [19:18:21] cool, the LEO missions will be a true test [19:18:39] doesn't look too bad [19:18:51] definitely [19:19:01] you can make the change if you want, Ryan. So that you have the full PAD [19:19:08] MCC project in VS [19:19:13] RTCC_Mission_D.cpp [19:19:19] line 2158 [19:19:24] sprintf(form->paddata, "Carnarvon AOS %s LOS %s, Hawaii AOS %s LOS %s", buff1, buff2, buff3, buff4); [19:19:36] basically just changed "\n" into ", " there [19:20:04] and then when I loaded your scenario I just did a "reset state" in the MCC debug menu [19:22:58] sounds good [19:23:46] almost LOS Hawaii [19:24:12] I'll keep the AOS times as they are [19:24:23] I think for now it's best to adjust the HGA pitch angle [19:24:42] I just need one more click down [19:24:46] and it will track [19:25:27] https://www.dropbox.com/s/ci3uj80pgignzkr/Screenshot%202021-03-16%20152428.jpg?dl=0 [19:27:17] yeah I guess 45° pointing error I just a bit too much [19:27:24] one click more would be 30° [19:27:29] is* [19:28:11]