[17:03:07] NASSP Logging has been started by alexb_88 [17:03:10] .tell indy91, PR sent with some CMVC fixes [18:24:50] morning! [14:45:51] morning! [15:10:37] Hey Matt [15:18:02] how's it going today? [15:18:30] Messing around with ESP32 for a college project [15:19:34] Need to use the iPerf example to do some wifi speed measurements and needed to patch it to toggle the RF switch on the board for the external antenna and enable a proprietary 802.11 extension [15:25:16] that sounds interesting. [15:44:42] Yeah, we need to do some testing next week to see what range and throughput we can achieve using that mode. [15:45:26] It's all C running on a FreeRTOS implementation. Takes some getting used to but its quite fun [15:45:45] :q [15:52:39] Afternoon [15:52:54] hey [15:57:31] hey [15:57:38] PRs have been merged [16:01:46] awesome [16:22:36] hey [16:28:12] hey alex [16:29:41] hey, I merged your PR [16:30:33] thanks [16:38:41] remember how I said I didn't want to add any more new LVDC features? Well about that... [16:39:16] found some issues with switching between time bases, so I implemented the whole switch selector function from that LVDC example code [16:40:08] most alternative time bases are really just interrupting a sequence of switch selector commands, sending out the alternative sequence, and go back to where they started [16:40:45] I had a lot of bugs related to time bases and I am happy I could delete a lot of that code [16:41:30] when in doubt, implement it all :D [16:41:53] there is just two weird things with this document [16:42:08] it doesn't mention timebase 4A (S-II/S-IVB direct staging) at all [16:42:18] where it is usually very complete [16:42:57] and also, the Saturn IB EDD talks about a hierarchy of switch selector sequences. Class 1 is the most important and can interrupt class 2 etc. [16:43:14] and this document seems to completely mix up class 1 and 2, including in variable names etc. [16:43:44] or not mux up, rather class 1 is class 2 and the other way around [16:43:47] mix* [16:46:12] so how to teat TB4a and TLI inhibit/returning to TB5 are the only things not 100% clear to me [16:46:16] treat* [16:47:44] good thing though is that they used an Apollo 14 LVDC listing for this code transcribed to other programming languages [16:47:54] so it even has code for the lunar impact APS burns [16:54:46] ah nice [16:58:38] I see the saturn1B has the SaturnHasCSM() flag, probably for Apollo 5 [16:59:12] so I guess this is a case where the VC shouldnt be loaded? [16:59:47] SaturnHasCSM() is a Saturn class function [17:00:26] but that CSMAttached flag is mostly pointless now [17:00:39] there won't be support in the Saturn class for any CSM less mission [17:00:48] right [17:01:10] AS-203 will be build with stages [17:01:34] does the Apollo 5 scenario as it is now use the saturn class? [17:01:41] I don't think so [17:01:49] ok [17:02:17] yeah, that is stages [17:02:22] S-IB-4:ProjectApollo/nsat1stg1 [17:02:25] I just wanted to be sure since now the VC is always loaded 1st in saturn class, and was wondering if there is still cases it shouldnt be [17:02:25] S-IVB-204:ProjectApollo/nsat1stg2 [17:02:31] LM-1:ProjectApollo/LEM [17:02:52] we don't have to delete that flag and the SaturnHasCSM() function right now [17:03:03] but I would say there is no requirement to check it anymore [17:06:46] the long term plan is to move things out of the Saturn classes and eventually rename it to CSM [17:08:32] yeah [17:09:01] I thinik the only time the VC isnt loaded yest is when buildstatus is less then 6 [17:09:12] but there is an issue with that [17:10:06] the custom ClearMeshes() I added only deletes from mesh 1 upwards so if there is no VC yet it should start from 0, like the normal ClearMeshes() [17:10:27] because buildstatus less then 6 has calls to ClearMeshes() [17:11:07] only affects the roll-out scenarios I guess [17:11:13] yeah [17:11:27] and that also is (very long term) going to assembl separate stages [17:11:31] but what I can do is add an extra check in ClearMeshes for now [17:11:53] so that it clears all meshes when buildstatus < 6 [17:16:28] hmm does the saturn1B also use the buildstatus flag? [17:17:25] don't think so [17:22:23] so I now made it, if buildstatus < 6 delete all, else delete starting from 1 [17:50:00] doesn't sound like very clean code, but good enough haha [17:52:03] true lol [17:56:01] brb, gotta leave the wifi for a bit [17:57:46] indy91, I am experimenting with using the same AID structure as the 2D panel for switches... i.e. AID_ATTITUDE_CONTROL_SWITCHES and that would include all the switches in that row [17:58:48] hmm, I guess panel areas that work on the 2D panel should also work in 3D, on the mostly flat panels [17:59:01] each switch already has information about its position in the row, so maybe I can find a way to use that for the VC [18:00:02] my idea right now is to have CheckMouseClickVC(int event, VECTOR3 &p) convert to int mx, int my and then call CheckMouseClick [18:01:34] oh interesting [18:01:37] I just need to find a way to convert the p.x, p.y which is a 0-1 range into whats required [18:01:40] mx my [18:01:59] hmm, that is probably pixels, right? [18:02:06] ideally it needs to access the size of the original AID [18:02:09] might not always be the same conversion [18:02:11] yeah [18:28:00] morning! [18:31:51] hey Mike [18:32:04] hi [19:07:22] @indy91, if I were to dig through some of the csm electrical, is there any thing I should steer clear of while you and alex are working on the VC? [19:10:16] hey Mike, anything from Debbie yet? [19:10:29] n7275_, no, I don't think so [19:10:32] yep [19:25:18] https://photos.app.goo.gl/9pnJrPszcJe83DCBA [19:29:19] indy91, does the AddSwitch function for the VC support sending multiple switches under the same AID? [19:30:01] thewonderidiot, oh god, that sounds like I was right [19:31:02] MainPanelVC.AddSwitch(&RCSAscFeed1ATB, AID_VC_RCS_ASC_FEED_TALKBACKS); [19:31:03] MainPanelVC.AddSwitch(&RCSAscFeed2ATB, AID_VC_RCS_ASC_FEED_TALKBACKS); [19:31:04] MainPanelVC.AddSwitch(&RCSAscFeed1BTB, AID_VC_RCS_ASC_FEED_TALKBACKS); [19:31:04] MainPanelVC.AddSwitch(&RCSAscFeed2BTB, AID_VC_RCS_ASC_FEED_TALKBACKS); [19:31:07] it does [19:31:31] right [19:31:51] I am trying to create a row of switches that share the same click area (AID) [19:32:09] but only the 1st switch works in the row [19:32:55] the AID is registered as quadrilateral [19:33:24] let me look at this Comanche stuff for a few minutes, I'll look at it then [19:33:43] ah sure, no rush [19:33:56] thewonderidiot, photo quality isn't great [19:34:13] yeah [19:34:15] it's good enough though [19:34:17] what's that procedure. V4N1E 3771E [19:35:27] haha I was scratching my head about that and was briefly worried I had an erasable problem [19:35:46] but I think what they're going for there is displaying 3772 in R2 [19:35:58] which is VGDISP [19:36:30] yeah [19:36:50] and then V21E? [19:36:54] doesn't look like it [19:37:18] and 3653 which is DELVSAB [19:37:23] I didn't want to be right [19:37:26] haha [19:37:46] so basically copying VGDISP to DELVSAB [19:37:50] so then do you think Comanche 45 actually used VGDISP instead of DELVSIN? [19:38:31] in P40 [19:38:34] ah right, that was the second part of my theory [19:39:00] well we knew for sure that the VLOAD ABVAL; DELVSIN; STORE DELVSAB was new [19:39:09] seems like the easiest fix [19:39:14] but there was a question of if it was DELVSIN or VGDISP [19:39:15] not necessariy the best [19:39:34] and if it's VGDISP I guess based on that procedure it would be DLOAD, and there would be no ABVAL? [19:39:39] or SLOAD even [19:40:08] but even then that doesn't make things one word shorter like I need... [19:40:36] I've already forgotten half of the revision history of this haha [19:40:56] CA VGDISP; TS DELVSAB would accomplish this in one less word if it were in basic... but this whole chunk is interpretive [19:41:46] right, also an option to do this procedure in code [19:42:03] but that seems unnecessary. If you are fixing the code might as well do it properly [19:42:18] let me reiterate. Colossus249 [19:42:25] VGDISP and DELVSAB have the same address [19:42:37] P30 stores the DV magnitude in VGDISP [19:42:44] and P40 then uses DLEVSAB, same thing [19:43:05] between C249 and C44 they split the addresses of VGDISP and DELVSAB [19:43:57] so C44 has this basically like C249, right? [19:45:25] in that those three words (VLOAD ABVAL; DEVLSIN; STORE DELVSAB) are not there at all [19:45:26] yeah [19:45:58] which C55 does [19:47:20] so C45 still has to calculated VGDISP from DELVSIN, in P30 [19:47:30] calculate* [19:53:19] what do you mean, still has to? [19:53:26] is that something that C55 no longer does? [19:53:44] C249 does it, C45 also still did it [19:54:02] yes I got that, but the question was, does C55 do it [19:54:52] C55 still stores in VGDISP, for display in P30 [19:55:03] so I'm not sure what you're saying then -- all three are the same? [19:55:15] in P30 yes [19:55:37] I'm just slowly going through this in my head, the many versions confuse me haha [19:55:42] haha gotcha [19:56:39] as per the the anomaly report they likely added the DV calculation to P40 [19:56:57] and not just copy over the VGDISP to DELVSAB [19:57:06] from 44 to 45 [19:57:09] I think the end result of this is that we haven't learned anything we didn't already know here lol [19:58:16] what would DLOAD VGDISP, STORE DELVSAB do? [19:58:44] instead of DV calculation. Maybe the DV calculation wasn't added until after C45? [19:59:03] it would take the same number of words to do, so it wouldn't help me with bank offsets [19:59:22] it's just another option to try if we manage to align the bank but still have a bad checksum [20:00:17] we need one word fewer than C55, right? [20:00:24] somewhere yeah [20:00:49] or I have a different, bigger problem, which is also possible :D [20:02:13] but if we just change DMP DELVSAB to VGDISP then we are 2 words short [20:04:29] so the anomaly report mentions P41 [20:04:59] is S40.1 called by P41? [20:05:56] back in a bit [20:09:49] DMP? [20:23:18] well further down [20:23:29] where DELVSAB is used [20:25:33] oh I wasn't really done summarizing yet [20:25:40] oh gotcha [20:25:41] lol [20:25:46] C55 code says THUS PERMITTING MODULE-ONLY CHANGE [20:25:54] that has to be the change from 44 to 45, right? [20:25:57] yep [20:26:09] and then the document you got from Purdue [20:26:18] change document from 45 to 55 [20:26:31] ABVAL of DELVSIN is not marked as the change [20:26:49] right, because that document was using 45 as a starting point [20:27:01] there never was a programmed guidance equations for 44 [20:27:02] it marks 2 lines, probably [20:27:14] one was that change from DMP to DMPR [20:27:31] but it seems to also mark that line with BURNANG = [20:27:48] I think that's where I thought maybe that didn't say DELVSAB before, but VGDISP [20:28:11] ohhhh [20:28:18] gotcha [20:28:36] which would make no sense if it already calculated DELVSAB above [20:28:37] other than the DMPR though I think the C249 and C55 code is the same there [20:28:41] right [20:34:31] so yeah I guess going for C44 first before C45 is still the best way forward [20:34:52] and then figuring out which addresses could not have moved between the two based on references from other modules [20:37:26] there still is that other bank error, right [20:37:45] and I am not seeing any more C44 only anomalies [20:44:26] yeah, so this is in bank 16 [20:44:40] and then bank 17 has some TVC initialization stuff in it maybe? [20:47:41] ah right, ATTINIT [21:04:06] AlexB_88, are you using the switch row for the AddSwitch? [21:04:50] MainPanelVC.AddSwitch(&ManualAttRollSwitch, AID_VC_ATTITUDE_CONTROL_SWITCHES); [21:04:56] thats the 1st one in the row [21:05:03] I have them all using that AID [21:05:37] oh, now I get it [21:05:44] so no, you can't actually do that right now [21:06:04] the redraw should work with multiple switches on one AID [21:06:08] but not the mouse click [21:06:13] I had only set that up for meters [21:06:43] ah, right [21:09:09] ok so for this, it would make sense to implement some code handling panel areas for more than one switch [21:10:38] yeah [21:10:44] either using switch rows [21:10:58] or adding a new type, panels [21:11:29] but one panel area per switch row would work [21:11:43] right [21:12:20] this is how I have been using to access the normal CheckMouseClick [21:12:21] int mx; [21:12:21] int my; [21:12:22] mx = int(p.x * 292); [21:12:22] my = int(p.y * 29); [21:12:23] CheckMouseClick(event, mx, my); [21:13:06] that is just for testing one row, I need a way to know the size of the row [21:13:15] and not * 292 etc [21:14:06] PanelSwitchesVC probably would get a AddSwitchRow function [21:14:44] SwitchRow::CheckMouseClick iterates through all switches to do the mouse click check [21:14:53] it's nearly the same for the VC [21:15:01] just the vector p and not mx, my [21:15:14] and if it can send the dimensions of the row that would work great I think [21:15:39] hmm [21:16:01] the more I think of it, the more it seems like a better idea to keep CheckMouseClickVC separate [21:17:16] you need a way to know the position of each switch in the row [21:17:36] the already registered x and y would have that [21:17:57] SSU seems to do a conversion like this [21:18:06] mx = (x - p_a.x) /(p_d.x - p_a.x); [21:18:07] my = (y - p_a.y) /(p_d.y - p_a.y); [21:20:06] p_d and p_a are the VC mouse region in the panel area I think [21:21:00] it's a difficult balance [21:21:11] do we implement lots of duplications for 2D and 3D [21:21:27] or keep things the same, but making it harder if we ever go VC only [21:24:40] yeah, I think some things apply well for both already [22:19:34] night! [13:27:45] Morning [15:08:28] hey [19:26:49] whoops. got destracted and left the house for a while [19:38:54] hey [19:41:42] hey Alex [20:10:35] hey [20:17:57] indy91, so did you have any ideas on how we could make the switch rows for the VC? [20:21:04] maybe not necessary yet, but the advantage is reducing the amount of AIDs and making the click-modes quadrilateral [20:21:25] I mean, I'd like to steal the concepts SSU uses, they work quite well [20:21:40] it's just adapting them for NASSP, reusing stuff for the 2D panels etc that is tricky [20:22:47] right [20:23:15] I'd rather have full panels than switch rows [20:23:35] there are still too many switch rows [20:24:32] yeah, makes sense I think that is what we want long term [20:25:34] I mean, if you can come up with the framework of it I can do the work of converting everything to it, like the animations [20:26:01] yeah I'll take a look at it soon [20:29:18] I cant do much work now anyway as im in Florida [20:33:25] they'll invent computers in Florida eventually [20:33:55] lol [20:36:21] well, I have my laptop... a good thing since I am staying in a all-apple household :D [20:48:30] Hi [20:50:35] hey [21:34:19] night! [22:57:30] I think I managed to simulated voltage drop with increasing load on the fuel cells [23:00:14] Nice. [23:01:10] I was just playing around with the fuel cells. Turns out you can't run both MNA and MNB off FC2 [23:01:38] Had a FC BUS disconnect and lost both buses [23:02:05] Already upinked a new state vector and clock update... now I need to get the platform back [23:02:27] The FC BUS DISCONNECT light is stuck for some reason though [23:29:40] Okay so the stuck C/W light isn't something I'm doing in my branch. good to know [00:06:57] might be this piece of code: SetLight(CSM_CWS_FC_BUS_DISCONNECT, ms.Fc_Disconnected && (Source == CWS_SOURCE_CSM)); [00:10:24] Yeah, I forgot to set the disconnected fc switch to off :p [00:11:00] Got to align the IMU to GDC though, you don't do that often [00:11:05] Usually the other way around [00:11:33] V74 is useless though. The ground station doesn't recognise the downlink list [00:17:05] ahh, yep the light works if you set the switches in the right position, lol [00:17:39] Yeah, pretty dumb on my part. Already had the debugger connected when I found out haha [00:18:19] Checking the other systems now. The S band lost lock, don't think anything else is outta wack [00:22:19] well I did the exact same thing too, I've got about 15 tabs open in visual studio I need to close now [15:51:13] Hey Thymo. I saw your comment on the PR. good thoughts [15:52:21] I don't think it would be hard to add transient behavoir to the fuel cells at least as fars as reactants and avaliable power are concerned. [15:53:18] s/fars/far [15:56:33] I'd also like to add clogging back in so that purging actually does something. I think Markus disabled it prior to 2009. [15:57:59] Also pH and temperature-efficiency aren't simulated [17:32:49] Hey. Just came back from visiting the grandparents [17:33:19] n7275: Yeah, I'm not sure why that was ever disabled. Would make purging useful again [17:33:56] Temperature is also a thing. That makes it so that our fuel cells can be restarted even if they've been frozen solid. [23:40:06] Ooh just did P23 and am still right on the money with my state vector. Range and range rate are all balls [01:29:10] nice! [02:12:18] I reenabled clogging. it behaves as expected when on pannel 1-3 and runs backwards in any other view... [02:15:11] some update/refresh function is only getting called on main panel [02:38:37] nope, nevermind. it's just instable at higher values of simdt [02:38:55] typical eulers-method problen [02:39:10] **problem [13:39:31] hey [13:41:44] hi [13:49:21] hey [15:45:19] hey [15:49:14] morning Alex [15:55:38] hey [16:06:45] whats up? [16:18:58] some LVDC bug fixing [16:19:53] there actually is one right now, in the current version of the LVDC, if you inhibit TLI after the APS ullage burn has started you get a stuck on S-II sep light [16:20:39] the Apollo 8 S-IVB flight test plan doesn't switch that off [16:21:11] seems unlikely, but this could have happened during the Apollo 8 mission, if that isn't just an error in that document [16:35:09] ah, so a bug in the real thing too [16:36:24] well potentially [16:37:59] doesn't get mentioned in the mission rules as it wouldn't harm anything [16:38:06] and it could be fixed by uplink [16:54:51] I am at the stage (again) where I am mostly fixing smaller bugs, so maybe I can release the update within a week [16:56:18] nice [16:56:31] looking forward to give it a try [16:56:52] not that I really can before December 1st :D [16:57:05] then I have good timing [17:11:25] back in a bit [21:28:53] night! [21:38:33] same [02:30:46] I have an extremely silly thing to ask here. [02:31:55] In the Apollo 13 movie, there was a Mr. Coffee maker, and..... it couldn't have been there, as Mr. Coffee was 1972. In the movie it also was a Mr. Coffee II https://i.imgur.com/XcIg2sk.png [02:32:09] Now discounting that this was made up, let's take their comment seriously [02:32:49] So 1625 watts (peak and brewing of course) https://i.imgur.com/CeF35os.png [02:33:05] unless they meant running for 9 hours on just the hotplate [02:33:54] So the question is at that point in the mission, how much did they have left in the batteries, amp hour wise or otherwise, was this just a throw away line or was there actual math nerd-age involved in that? [02:35:35] (or was there a different coffee maker, eg a percolator, and a similar thing was actually said about in the mission for real (other than just to add drama in the movie))? I know this is a silly thing, but I figure with enough people doing simulated 13 runs here, someone has a answer on the power left :D [02:36:45] either way I am glad to have figured out that the brave crew trying to support apollo 13 wasn't working off drip coffee for some reason. Just feels right. [04:16:16] hmm, interesting question [04:20:14] ~600 amp hours at 28V is 16800 Wh /1625 watts is 10.3 hours assuming a fully charged LEM [06:58:28] indy91, I had a major comanche breakthrough :D [06:58:36] going after 44 was definitely the right move [06:58:57] looking at cross-module references, they definitely had to pull some shenanigans for revision 45 [06:59:21] probably inserting a jump from bank 16 to bank 17, doing the actual calculation there, and jumping back [06:59:28] but anyways [07:00:01] I switched over to using C44 checksums, deleted the lines added for C45, and started fiddling [07:00:39] and it turns out that if I restore LDPLANET back to its original implementation (including the 1/SQRT3 factor, but using STAR instead of STARSAV3), then I get correct checksums in every single bank except for 16 [07:01:02] that includes 17, which is where K2VAL/K3VAL *and* the TVC initialization code live :D [07:01:12] so we're *super* close [12:55:15] Damn, Mike. That's awesome! [17:22:19] hey [17:23:26] found something that may be a VC bug [17:24:28] I'm testing my fuel cell modifications, csm in lunar orbit [17:24:40] left it running for about 4 hours [17:25:22] and the DC voltage needle has disappeared [17:25:56] voltage should still show at ~29.8 volts [17:27:33] looks similar to the LM signal strength gauge disappearing-needle issue [17:31:10] hey [17:31:19] yeah it's the same type of gauge [17:33:27] does the bug go away if you reload? [17:34:33] oh and do you have the "absolute animation handling" option enabled? [17:37:09] not sure I do. [17:37:46] nope, wasn't on [17:37:55] that might help [17:38:19] not that we should build a VC that requires that option, but I think we basically do [17:38:53] yep, reloading and enabling fixed it [17:39:14] morning! [17:40:10] hey Mike [17:40:25] congrats on getting all those banks right [17:40:51] n7275_, it might be that the animation state drifted over the hours [17:41:08] in the DeltaGlider VC for example there is some code that prevents the drifting, I think [17:41:19] we currently don't have that, so absolute animation state handling helps us [17:42:17] thewonderidiot, so what would be the remaining difference in bank 16. Maybe something in a different part of it? Not S40.1 [17:42:40] yeah I'm not sure, nothing caught my eye at a first run through [17:42:53] there is more TVC stuff at the end that could be involved [17:43:23] what does C44 use in S40.130 [17:43:26] F or FANG? [17:43:44] uhhh pretty sure it's F [17:44:04] didn't they already add padloaded FANG? [17:44:20] if they did then I'm missing that [17:46:34] I could better help you if I could look at the current C44 code you have haha [17:47:20] and yes, C44/45 should already have FANG [17:47:33] so S40.130 should probably use it [17:48:57] huh, I could have sworn it was only K1VAL haha [17:49:02] which PCR was that again? [17:49:44] GSOP has F_imp, which is FANG [17:49:47] in erasable [17:49:52] 729 maybe? [17:50:13] yes [17:50:14] oh yeah sure enough [17:50:23] "K1 & FANG in Erasable, IMPULSE Burn" [17:50:27] whoops [17:50:56] I think it didn't come up because you usually worked backwards from C51 [17:51:05] but maybe you took this section from C249 [17:52:28] at least that's why I didn't think about FANG before :D [17:52:45] haha [17:53:01] well that's not enough to totally fix it [17:53:16] went from diff=21237 to diff=17302 [17:54:02] so this part of the code, is that generally taken from C249 or C51? [17:55:13] that whole log section is mostly from C51, except for removing the anomaly fix, DMPR->DMP, and restoring K2VAL/K3VAL to fixed memory [17:55:40] https://drive.google.com/file/d/1nOMPylbOS_EtUIUxKVgsEnwu6ZuhQoxV/view?usp=sharing [17:55:41] hmm, how did FANG end up as F then [17:56:03] because I thought only K1VAL had moved to erasable [17:56:07] that was an intentional decision lol [17:56:11] just a wrong one :P [17:56:30] anyways, that is my whole Comanche 44 folder as assembled, after putting in FANG [17:56:38] great, thanks [17:58:49] a lot of this should be identical to C249 [17:59:05] a lot of what? [17:59:53] P40/P41 code [18:00:22] and especially S40.130 is in the GSOP the same, just K1 and FANG from erasable [18:01:19] K2 and K3 changed from C249, but even if I gave you bad values, that alone can't be the bank difference, right? [18:01:40] well, they are double precision [18:01:41] luckily those constants are in bank 17 which currently has the correct checksum [18:03:07] oh right, scrolled too far [18:03:35]