[17:23:10] NASSP Logging has been started by rcflyinghokie [17:23:12] Haha [17:23:28] indy91, I'll take this round of questions :P [17:36:27] rcflyinghokie, if you have a chance and want to test my specific heat update I have a script that upgrades old scenarios [17:36:31] https://gist.github.com/n7275/8cab7e348507ff4bce4749d09e2c3894 [17:36:39] I will let you know [17:45:19] ha thanks [17:51:05] morning! [17:55:51] it was all LM activation stuff so I am intimately familiar :P [17:55:58] Hey Mike [18:06:15] hey [18:12:57] Good add to that post [18:13:20] My "switch to XX" and "wait for MCC update" commands are spaced to kind of take that into account [18:13:29] Usually works pretty well [18:14:18] right [18:20:50] I don't know how far off the flight plan we are on average now [18:21:00] the TLI cutoff being off had a big impact on that [18:21:19] that error doesn't get corrected until MCC-2 [18:21:49] hopefully it's not 25 minutes off anymore on Apollo 10 :D [18:46:32] Hmm I haven't flown 10 in a while [19:00:30] Apollo 10 already is 10 minutes later by default [19:00:50] non-zero midcourse correction to get to the same orbit as Apollo 11 [19:01:00] and the flight plan has that at MCC-1 [19:01:15] but in reality, and for us, that happened at MCC-2 [19:01:43] and that delay have the actual mission that 10 minutes delay [19:01:49] gave* [19:16:22] What are our plans with the voice check item in the MCC menu? What's its intended use? [19:20:53] Also, what debugging stuff do we have turned on in the VC? My debug build grinds to a halt when I try to use it. [19:26:05] good question on the voice check, I never quite understood how it was intended to be used in our case [19:35:56] dseagrav implemented that, I'm not sure either :D [19:42:48] Does anyone want to do something with it? Right now it's just confusing people. Might as well rip it out. :P [19:50:04] Just pull it from the menu, I don't see why not [19:52:17] I'll look at it [20:04:58] The AGC in Turry's scenario still does weird stuff [20:05:52] thewonderidiot: Coming out of standby the AGC appears to do a TC to 4000 and then during that cycle Z is set to 3336 [20:06:53] So it's not the interrupt [20:21:11] that is very strange [20:23:01] O_o [20:28:08] What the fuck [20:28:26] This is what the AGC is doing: [20:28:35] INDEX 1754 [20:28:40] TC 4 (INHINT) [20:28:48] Where did that index come from? [20:29:06] So the INHINT is transformed to a TC to god knows where [20:32:05] State->IndexValue is set to 1754 in his AGC during standby. No idea why. [20:38:30] oh man [20:38:50] that's probably a yaAGC bug and he just got extremely unlucky and happened to get into standby exactly after an INDEX instruction [20:38:58] GOJAM isn't clearing IndexValue is it? [20:39:08] Nope [20:39:12] lol wow [20:40:11] He probably pressed PRO while an INDEX 1754 just executed [20:40:39] yup exactly [20:40:42] That value is only persisted between the INDEX instruction and the instruction to be indexed. After that its zeroed [20:41:07] What are the odds of that 1. happening. 2. happening on stream. 3. while one of us is watching [20:43:40] very very small :D [21:43:25] indy91: Just opened a PR removing some dead code from our agc_engine [21:54:07] thewonderidiot: I mentioned this last time but what do you think about doing GOJAM coming out of standby instead of going into it? That ensures no funny business happened in the meantime. [21:54:45] I think all that needs to be done is setting TriggeredAlarm here https://github.com/virtualagc/virtualagc/blob/master/yaAGC/agc_engine.c#L2024 and removing the one right above it. [22:07:21] Thymo, PR looks good [22:07:25] good night! [22:07:26] Merged [22:07:29] See ya [22:14:34] Thymo, it would probably be best to have it done in both places [22:14:50] Sure [22:14:52] otherwise you might end up with channels with stuck outputs throughout standby [22:15:08] Ah yeah that's a good point [22:15:22] and the RESTART light handling might need a bit of additional logic [22:16:43] RESTART light behavior needs another look anyway. yaAGC lights it when the CycleCounter is 0 to simulate power being turned on. [22:17:07] That works for the standalone version but in NASSP we had to comment it out because it would come on everytime you start a scenario. [06:17:04] I think I found the source of the PCM desync issue [09:11:04] Morning [11:14:48] morning [12:25:08] What did you find out about that PCM desync issue? [12:33:13] I'm not exactly sure why the old values were what they were. I almost think it was a typo. [12:33:48] there are two multiplexed words in our pcm. 52 and 83 iirc [12:35:01] frame_addr controls which value this word sends in a given frame [12:35:15] lbr mode shouldn't even have frames [12:35:40] it should be like the our lm's [12:36:01] Where is that bitstream specified again? Only in the AOH? [12:58:25] systems handbook [13:29:03] Looking at the systems handbook the LBR format has no sync words, ours does. I'm curious how LBR is so supposed to sync then. [13:46:51] on pdf page 121 of the csm 114 systems handbook [13:47:20] doesnt that imply that they are the same just at a lower rate [13:48:10] No I see it now. Pag 147 inside the digital multiplexer, middle column, bottom 3 rows. [13:48:27] Thats where the sync words are hardwired into those gates. [13:49:03] I suppose those are strobed in LBR too, although it doesn't show it in the LBR format in the bottom left of that page, it does show it for HBR. [15:01:46] hey [15:02:19] hey Matt [15:03:26] your PR looks too easy :D [15:03:35] for the PCM [15:05:11] I'm not really sure why frame_adr was running from 0 to 4 in lbr mode. it isn't even used there [15:07:46] I tested switching back and forth around 100 times and it seems to reliably sync back up in hbr [15:09:32] ah this code in LBR was screwing up HBR? [15:09:53] it's too bad the Meadville forums are broken now. would be really interested in looking back around the time telemetry was added [15:10:40] yes. the code at the end of the lbr generate function [15:11:06] telemetry worked reliably if you loaded a scenario in hbr mode [15:12:04] hmm [15:12:07] but if you switched it would work but only about 1 out of 5 or so times. [15:12:09] frame_count was wrong, too? [15:12:19] that does get used in LBR [15:12:40] yes, in our implimentation [15:12:42] how did that even work correctly in the telemetry client [15:12:57] does this also need a change in the telemetry client? [15:13:16] I dont believe so. [15:13:44] so right now it goes through the telemetry code with frame_count == 5 [15:13:59] but doesn't send anything? [15:14:35] just the 0.0 in the default of the switch-case [15:15:00] ooh the frame count gets send on telemetry [15:15:00] which is why some of the multiplexed analog words would be 0.0 [15:15:24] and the telemetry client works right now because it just processed the data with whatever frame count it gets [15:15:51] and nothing needed processing with the frame count being 5 [15:16:47] in LBR [15:20:31] ah then the frame_addr and frame_count code is identical in HBR and LBR [15:23:44] nice find, approved. Thymo can take a look, too, if he wants. [15:23:48] So data was 0 in the telemetry client before the patch? [15:24:03] Yeah, I want to give it a run after dinner. [15:24:44] in LBR it was sending an empty frame every 5 frames [15:25:10] telemetry client didn't care because it processed the data based on the telemetered frame number [15:25:57] n7275, both lines you changed were contributing to the desync issue, right? [15:36:57] In my experience the telemetry client doesn't care about a lot of things [15:47:53] the line that was changed to 49 was the cause of the desync issue [15:48:27] the other line was just sending a frame of zeros [15:49:14] ah ok [15:49:29] ...while explains why there were a strangely large amount of zeros in the data my telemetry logged logged [15:49:37] haha [15:49:47] not me being lazy and not adding enough telemetry data! [15:50:27] oh I got scammed by the MSC memo btw. There is an array of size 27 and then last 3 values get used as integration step sizes. [15:50:46] except the array only defines the first 24 numbers [15:50:52] ??? [15:51:09] the other 3 must be set elsewhere I would think, but I haven't found where [15:51:23] yet [15:52:24] oh strange [15:52:53] in BLOCDA [15:53:01] HARRAY on PDF page 75 if you want to have a look [15:53:29] sure [15:53:30] ooooooh [15:53:31] haha [15:53:39] I can't read FORTRAN data I think [15:53:43] there is this [15:53:48] 4*1.D0 [15:53:59] that doesn't mean 4.0 [15:54:05] that means 4 times 1.D0 [15:54:06] right? [15:55:03] I think so. it tends to interpret things very literally [15:55:28] I was putting the logic to determine the step sizes in a MATLAB script [15:55:34] so I just blindly copied the 4*1.0 [15:55:59] so just 4 times the 1.0 and the last 3 values of the array are just like I thought [17:24:13] morning! [18:54:05] hey Mike. what's up? [18:55:26] http://apolloguidance.computer/rope/ [18:55:31] first version is online :D [20:25:59] looks awesome :D [22:13:10] night! [22:35:43] n7275: Merged your PR [23:15:04] thanks [15:00:44] https://stackoverflow.com/questions/16358418/how-to-avoid-merge-commit-hell-on-github-bitbucket/16358699 [15:52:42] hey [15:53:51] good info [16:36:12] hello [16:37:57] hey Niklas [17:07:05] fun fact, the common cold hasn't died out, despite Corona [17:07:12] I have empirically tested that with myself [17:23:43] oh that's no fun. [17:28:19] morning! [17:28:23] boo, yeah, that sucks [17:28:44] definitely not vaccinated against this one haha [17:29:43] the MSC memo continues to give me confusing information. It doesn't seem to use different step sizes in Cowell vs. Encke integration. I thought the whole point of using Encke's method was larger step sizes [17:29:55] but maybe I am just overlooking something in the Fortran code (again) [17:32:12] the AGC determines its integration step size with a calculation based on the orbit [17:32:24] this RTCC code has a lookup table, based on radius [17:32:31] larger radius = larger step sizes [17:32:43] position vector radius that is [17:32:56] AGC version is probably a bit slower but needs less memory [17:39:19] I may spend some time this afternoon transcribing a bit more of that one [17:41:14] I also recently noticed that the Gemini rendezvous simulation FORTRAN II/FAP code in the virtualagc repo is something for which I do have a compiler and can run virtually unedited. [17:43:05] yeah, there is a bunch of interesting Gemini code and flowcharts [18:56:04] I think I've stared at this MSC memo enough for now :D [19:47:47] haha [04:42:59] Thymo I saw the link you shared earlier. should I be rethinking how I do my feature branches, and keep them up to date? [16:11:32] hey Nik [16:11:42] hey [16:12:04] feeling better? [16:13:38] a bit, yeah. Thanks for asking :) [16:15:56] good to hear [16:18:07] I had another idea for my DragUpdate branch haha [16:18:23] maybe I'll just merge it with drag reduced to 1/20th [16:18:33] That's what I have it set to in the RTCC at the moment [16:18:50] hardcoded drag coefficient if 0.1 instead of 2.0 [16:19:03] that would at least remove the randomness of drag we get right now [16:19:29] once I am confident that everything in the RTCC can take the drag into account I'll put it up to 2.0 [16:20:02] that's a good idea [16:21:04] a lot of the time when I'm working on something, im aiming for "how can I make this less wrong", before i focus on perfecting it. [16:21:42] most of the times when I haven't done it that way I ended up deleting the development branch again [16:31:16] I should probably get rid of the Apollo 7 MCC changes I did in that branch [16:31:19] and do them separately [17:09:21] hmm, got some scenario differences between the branches now [17:09:27] need to try and fix those [18:26:10] nothing I caused I hope [18:51:31] nah I did it to myself [18:51:42] did a few fixes to the Apollo 7 mission scenarios a month ago [19:00:38] ahh okay. there'll be plenty of time for me to break scenarios in the coming weeks :) [19:42:01] I've been thinking about what you said a few days ago about a mission scenario generator. that might be a bit out of reach at the moment, but it would be interesting to make a launch scenario generator. [16:08:46] rcflyinghokie, you got me, was just writing a reply for Wedge313 :P [16:08:56] haha! [16:09:31] I am working on thermocalcs now [16:10:50] ah great [16:20:15] I'll be getting my drag branch merged soon. But for now in reduced form, with only 5% of the actual drag. That shouldn't be too different from what we get now on average, but a lot less random [16:20:38] once I am happy with the RTCC taking drag into account I'll remove all the 0.05 factors [16:23:22] hmm, I am seeing a build warning that I hadn't seen before [16:23:33] in thermal.cpp [16:23:38] probably n7275's update [16:23:39] Q4 = (float)(100 * runner->Area * (runner->Temp - v->GetAtmTemperature()))*(v->GetAtmDensity()/1.225); [16:24:08] I believe the (float) takes care of the first bracket [16:24:17] but not the GetAtmDensity part [16:24:25] that returns double and isn't properly converted to float [16:25:02] don't think it is a functional issue, but would be good to test and get rid of the build warning [16:25:10] oh hi [16:25:24] hey [16:25:37] Visual Studio hasn't been reliably showing be build warnings anymore in a long time [16:25:41] me* [16:27:15] me too aparently [16:29:06] Its been hit or miss for me [16:32:22] Is the LM OHW set with the correct orientation and FOV to accurately track the lunar horizon during PDI? [16:32:28] Last I recall it was not [16:32:41] morning! [16:32:49] hey mike [16:35:00] Also, is there any keyboard workaround yet to deflect the ACA out of detent without a joystick (ie to stop the RCS on the lunar surface) [16:35:03] Morning Mike [16:38:51] OHW on the 2D panel? [16:40:02] we have a keyboard combination for the CSM minimum impulse controller. Maybe I could use the same for the ACA [16:40:09] OHW on 2d yes [16:40:17] deflecting it enough for out of detent, but not enough for the breakout switches [16:40:39] Would that work to null the error needles and stop the firing after landing? [16:40:53] have to try, not really sure where the threshold is for the DAP [16:41:57] I think it would use the proportional commands [16:42:18] breakout switches are used by the PGNS for min imp mode, I think [16:42:33] That sounds correct [16:43:07] and LPD [16:43:41] maybe you have to do out-of-detent little enough so that the proprtional command is still 0 bits [16:46:01] hmm [16:46:26] out of detent is its own channel assignment it seems [16:46:42] yeah, a separate input bit to the LGC [16:46:47] bit 15 channel31 [16:47:21] the way it is described in GSOP section 3 seems like it should work if you just return the ACA to center [16:47:36] but there is a separate control law for large commanded rates [16:47:43] maybe with keyboard the ACA is doing that [16:52:52] there is a breakout level for commanded rate of 0.6°/s [16:53:04] above that it switches to a different control mode [16:53:15] which probably makes the procedure not work [16:53:25] ACA out-of-detent [16:59:39] any way to see what its doing? [17:09:44] difficult, you can at least see if it's working looking at the attitude error [17:09:52] on FDAI error needles [17:09:57] or AGC output to it [17:14:28] Side note, there's an Apollo 7 question I redirected from the release work thread, I don't know the answer to it [17:16:37] I'll answer it [17:17:47] oh it's a different question from the release thread question actually [17:33:55] oh lol [18:15:52] oh wait a moment [18:16:07] the ACA with keyboard is using the Orbiter function GetManualControlLevel [18:16:36] and the default Orbiter has CTRL plus Numpad to get 10% of normal attitude controls [18:16:42] maybe that already works [18:36:14] it doesn't [18:36:21] I am actually seeing 3% deflection [18:36:31] and not 10% like the Orbiter manual says [18:41:10] oh [18:41:17] but that has to be a NASSP bug [18:41:27] GetManualControlLevel returns 0.1 [18:47:16] no I was looking at it wrong [18:47:22] out-of-detent is being set [18:47:40] so I think if you do CTRL plus Numpad, it commands 10% deflection of the ACA, set out-of-detent [18:47:46] and the procedure on the surface should work [18:48:12] I'm not getting an attitude rate from 10% deflection, but that is probably right [18:48:38] if the DAP is set to 4°/s it might be in the deadband [18:50:00] ha [18:50:26] that amount of deflection sets the input registers to the LGC to 1 and -1 [18:50:30] instead of 52 (octal) [18:50:33] for full deflection [18:50:55] sounds right [19:09:00] indy91, quick question on gravity models. every model I've ever seen uses the same table format with the Stokes' Coefficients and their uncertainties. why do these models not include zonal terms? [19:15:23] Ok so CTRL+numpad will command a 10% deflection? [19:15:32] yes [19:15:44] n7275, uhh, no idea. I thought they do contain zonal terms [19:18:35] rcflyinghokie, not enough to cause an attitude rate in any case [19:18:47] enough to set the out-of-detent signal though [19:19:04] but I have to test if it actually works to null the attitude error [19:32:35] they do. I was wrong [19:34:12] all of the C terms that are C(n,0) are included. C(n,0)=J(n) [20:13:04] indy91 is that with current implementation or did you change anything [20:58:58] without changing anything, should already work [20:59:17] just by using that Orbiter function to get the keyboard presses for rotational controls [21:14:51] Seems to be a better solution than turning mode control off after touchdown [21:45:44] libera crash? [21:45:59] Or just me [21:53:01] you and Thymo disconnected but I stayed on [21:59:02] probably just one server disconnecting [22:02:26] yeah, that sounds likely [22:02:30] good night! [22:03:12] you'll be happy to know I've made it a bit further with my fuel cell project [22:03:30] I'm no longer directly cooling the cells [22:04:00] they are cooled by hydrogen, which gets cooled by the secondary glycol loop [23:27:56] hydrogen + steam loop I should say [05:42:27] .tell indy91 I completely forgot about this https://www.youtube.com/watch?v=2fRg_AMXuJY 4k upscale, but not perfect by any means. some areas show a bit of progress although on others ht makes it harder to read [15:10:02] good morning [15:11:25] morning [15:22:47] Man with pre holiday stuff, I haven't found any time to work on the ECS [15:23:42] Playing damage control as PII snuck into one of our databases thanks to some idiots in another area of the government [15:55:35] Another potential VC issue https://www.orbiter-forum.com/threads/cryo-o2-pressures-between-2d-panel-and-vc-differ-apollo-7.40241/ [15:59:19] the 2d should be correct, correct? [16:19:06] speeking of damage control, I just got pulled away for a bit [16:19:15] rcflyinghokie: Probably. Worth confirming it with a debug line [16:19:31] had a 4 day weekend and spend all of them at the factory [16:20:20] yes, as far as I know the 2d panel is correct [16:21:08] So the VC scaling is off [17:05:08] I think most of the incorrectly scaled gauges are the multi-scale ones [17:38:47] makes sense