[13:56:50] NASSP Logging has been started by thymo [16:06:43] good evening [16:06:49] hey Niklas [16:07:08] ggalfi has a local branch with many changes [16:07:09] https://www.orbiter-forum.com/showthread.php?t=41580 [16:07:32] on 1st read, they seem quite good [16:07:58] but it may interfere with some of your recent updates [16:08:18] Hi all! [16:08:21] hey [16:08:29] hey there [16:09:02] Hi Indy, I think I'm looking for you [16:09:38] yes, that's probably true :D [16:09:53] that's an impressive list of changes you have done [16:10:25] so impressive and extensive that it might not be so easy to get them merged... [16:11:07] but one step at a time. I think it would be useful if you put your updated version on your Github NASSP repository, so that I can take a look [16:13:16] Ok, I can do that easily. The current version is based on 2020 Jan status of orbiter2016 branch [16:14:52] yeah, there are a few areas that you modified that I have worked on since January. Mostly the CDU. Made it just realistic enough to work right for auto optics/TVC [16:17:19] I guess the most challenging thing about getting your work merged is the tight integration of the subsystems connected to the AGC, and the Virtual AGC changes itself [16:17:45] that pretty much won't allow for parts of it to be integrated in the main NASSP branch [16:17:58] either most of it or nothing [16:19:55] Yes, the reason I touched so many things was that I wanted to move the CDU - AGC interaction more closer to the real (physical) implementation, and the original Virtual AGC worked in a totally different way. And I found a hybrid solution very nasty. [16:21:09] So I reworked (almost) every interface which is involved in this involuntary counter increment stuff. [16:22:53] I upload my version, then I get back to you. [16:22:57] sure [16:23:38] Mike (thewonderidiot) actually did a big Virtual AGC update for more realistic counters, but it got never merged to either Virtual AGC or NASSP as I could never bring myself to break so many things at once for a little gain in realism [16:24:21] the easiest thing to merge is probably your DPS thrust changes [16:24:46] I did implement something for throat erosion and the resulting increase in thrust about a year ago [16:25:01] but if your version is an improvement to that it can of course be updated [16:26:52] Apollo 11 throttle down happened way too late for use before my update. Even now it's about 15 seconds too late. But that could have multiple reasons, trajectory etc., not necessarily all the DPS thrust. [16:26:56] fo rus* [16:26:57] for us* [16:27:39] Yes, I've found it. Seemed to me it was based on the GSOP simulator specification. However the figures in that document is far lower than the values you may see in Apollo11-12 simulation printouts. [16:29:22] And you may change the trajectory to change the throttle down time but it will make a difference of a 1-2 seconds max. [16:29:29] if the MIT simulator was super realistic, multiple issues wouldn't have happened during actual flight :D [16:30:30] The main factor in throttle down time is the actual FTP thrust. [16:30:55] right [16:31:41] I remember being super excited that we got optics to work *at all* because nobody thought it would ever be accurate enough to track [16:34:19] On the MIT sim: you are right, but I have another explanation: they simulated some sort of worth case situation, so they may used a lowest allowed thrust value. If the real-life thrust is slightly larger, no one will complain about it :) [16:34:46] yeah [16:34:58] oh and about optics, I did some work on that cently as well [16:35:08] bit of CDU update, lots of auto optics update [16:35:20] I'm definitely interested in seeing your solution for that [16:35:47] I can't say that I am 100% happy about how the auto optics are driven in my update [16:37:14] Suzuran, ah yes I remember those days... I was totally amazed when I 1st saw the CSM make an SPS burn completely controlled by the vAGC [16:37:17] ggalfi: Does your implementation still light channel bits? It'd be a shame to break the real-AGC demo, even though it'll probably never happen again... [16:38:04] back then you were considered nuts to even consider flying anything but Apollo 7 under vAGC... [16:42:04] @indy91: What I have done for optics was based on the transfer functions found in Apollo 15 Delco. However the gains given there gave fairly large overshoot, so I downgraded them by a trial-and-error way. Now it still has a slight oscillation when it moves to a star automatically, but it is very smooth and a five-ball or 00001 accuracy could be [16:42:05] achieved in P52 [16:42:19] haha [16:42:31] so that's about the same problems and solutions I had :D [16:44:41] We (or the documentation) may have missed some amplifier gain. A factor of 100 could make some difference :) [16:46:20] AlexB_88: https://i.imgur.com/1hi6uDT.png [16:46:50] haha [16:47:21] First AGC meme I've ever seen. [16:47:24] that was back when multiple cores was expensive too [16:48:14] ggalfi: There's actually been more than a few over the years [16:56:20] Suzuran: on channel bits, I only changed the handling of them when it is internally handled by AGC. For example the Radar Enable bit (Bit4 Ch13) is handled by the AGC itself and only some strobe signals are forwarded to the radar hardware. So I put the code for that into a separate place executed exactly 3200 times in a second. But I've kept the [16:56:21] (real) IO channels as they are. Only wired out some fictious channels (like the coarse alignment channels) as they were no longer needed. [16:58:05] morning! [16:58:08] Awesome. Last I heard there were at least two people working on FPGA AGCs for use with NASSP after the real-AGC demo. [16:59:53] oh boy. I should make sure that I committed everything I did for that then [17:03:29] Anyway, I have to head to the office for a bit; I'll be back later. [17:04:40] have fun/stay safe! [17:08:25] hey Mike [17:08:36] you and ggalfi might want to talk about 1201/1202 alarms :D [17:09:47] yeah definitely :) [17:10:03] I've seen quite a lot of them during the past few months, sometime more than I wanted :) [17:11:03] in my experience it's very easy to get more than you want, and very difficult to get exactly the right amount, heh [17:18:15] Yes at the moment I'm quite close "optimum" (if we see it as optimum when any prog alarm appears), that if I do everything in the same order as LM5 crew did the first errors during P63 and P64 at a right time with the correct type. However in my simulation there 4 alarms during P63 and don't know many (but surely more than 3) in P64. My only idea [17:18:16] is the root cause CDU phase shift was not the worst case on the real LM5 just very close to it (say 80 degrees instead of 90). [17:22:46] However the appearance of errors are strongly depending on the exact timing of the actions. For example if I execute the 180 degree yaw maneuver too quickly and have LR lock sooner then (I don't know why) I don't get any error before the V57 + V16N68. [17:23:31] yeah, it's very finicky [17:34:25] I leave now. I try to upload my changes on my own github. Let you know when you can peek into it. [17:34:42] Bye [17:34:43] awesome, looking forward to it :D [17:34:45] see ya! [17:35:46] this is an exciting development [17:36:24] yes, but it will not be easy to get it merged [17:37:03] I'm seeing lots of work for me ahead :D [17:37:08] hehehe [17:38:52] his changes are also aimed at getting a very accurate Apollo 11 landing sim [17:39:08] so me might want to modify some things of it, to be more generally applicable [17:39:11] so we* [17:40:43] on my end, I got Apollo 5 into orbit as docked S-IB + S-IVB + LM + Nosecap docked together [17:40:52] oh nice! [17:41:10] it's mainly wiring that has to be added [17:41:17] e.g. commands from the LVDC to the S-IB [17:41:37] also, the S-IVB class needed some changes to work for a launch, as it usually only gets created in orbit [17:41:56] next up is nosecap and SLA deployment [17:42:18] the Nosecap is using the same docking port as the CSM will [17:42:51] the main disadvantage of docked stages is that aerodynamic behavior is more difficult to handle [17:42:56] right [17:43:09] and the LV IMU is a bit less accurate, maybe launch alignment issue [17:44:02] but it gets into a good orbit, not much to do and Apollo 5 would work with this [17:45:18] excellent :D [17:47:28] none of the bugs of my LEMSaturn class :D [17:47:37] hehehe [17:48:11] for me, I managed to knock out two whole banks of Sundance yesterday [17:48:20] got me up to 27/36 done, so I've passed the 75% point [17:48:27] only 9 banks to go :) [17:48:48] also finally identified some changes between 302 and 306, one of which I'm confident I can recreate, and the other I'm not sure about yet [17:49:37] what are they? [17:50:00] and yeah, reading the GSOP about the absent R65 I noticed how different P20 is [17:50:21] not from an astronaut perspective though [17:50:39] although there could be lots of differences in the additional display you don't normally get [17:50:43] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/MEASUREMENT_INCORPORATION.agc#L153 [17:50:52] the first bigger one is that [17:51:00] Sundance doesn't have "NEWZCOMP" at all [17:51:13] so that GOTO is missing and the NEWZCOMP subroutine is not present [17:51:18] Sundance 302, that is [17:51:42] there's a large offset there in Sundance 306 that strongly suggests it was added between 302 and 306 [17:52:07] nosecap deployed! [17:52:12] nice! \o/ [17:52:21] now I wait 10 minutes for the SLA... [17:52:47] hmm, can't say I am too familiar with measurement incorporation [17:53:00] never did a "deep dive" into the W-Matrix and all that related stuff [17:53:45] yeah [17:53:47] https://github.com/thewonderidiot/sundance/blob/master/b4_302.disagc#L2242 [17:53:53] the other change must be somewhere in the P20s/R20s [17:54:21] Sundance 306 has an additional 2 words between the start of the bank and CLRADMOD at 24,306x [17:54:37] unfortunately I can only narrow it down to half of the bank [17:55:06] and the GSOP doesn't help, because as far as I can tell the only change they made to the R20s in the Sundance 306 release of the GSOP, was something that was already in Sundance 302 [17:56:05] in addition to the big stuff there's several small differences in flag setting and restart checkpoints, any one of which could explain 2 words [17:56:57] doesn't sound like something that is documented in my usual reading list [17:57:05] more like last minutes fixes to make things safer [17:57:14] probably yeah [17:57:36] unless they did the N49 change... but I think that would be less words and not 2 more [17:57:50] I'll have to play around with it once I have a working build of sundance going [17:58:55] what was that about N49 again? [17:59:33] Luminary spawns a job dedicated to N49 display handling [17:59:45] in Sundance, R22 changes its own priority and displays N49 directly [18:00:02] ah, I see [18:00:15] changes its own priority lol [18:02:06] SLA deployment worked, looked a bit weird though [18:02:17] and the panels probably stayed attached on Apollo 5 [18:02:33] have to set the right bit there in the scenario [18:02:53] only remaining thing really is that the LM can undock from the S-IVB [18:03:17] commanded by the LGC through the programer [18:03:31] then Apollo 5 is flying with this. Lots of small issues still, but not too bad [18:03:37] flyable* [18:07:05] awesome [18:11:13] @indy91, I can't remember. was there some intrest or looking-into of adding tesseral perturbations (in addition to the zonal ones that orbiter simulates). I thought I remember seeing something about it. probably not the most important thing right now, but just curious. [18:12:02] well what I wanted to do was a bit of research and then make a Orbiter feature request for that, so that we could have a more realistic gravity model of the Moon [18:12:09] one that matches the AGC in the later missions [18:16:01] even on Apollo 11, they didn't target LOI-2 to a circular orbit [18:16:20] but one that becomes circular later one due to the gravity perturbations [18:16:36] the longer the mission, the more that becomes relevant [18:24:21] I've been playing around with GMAT. got me thinking. it would be nice if orbiter supported different, plugin gravity models such like it does Atmospheres. LP165 would be nice to have. [18:25:52] yeah, definitely [18:26:11] that's what I was thinking. Why does it only have that for the atmosphere??? [18:28:25] I even read through the cel_body part if the API, half expecting to find something. [18:30:08] yeah, if it was possible that way instead of the config file that would be ok [18:30:35] we are using our own solar system config files already, why not the dlls as well? :D [18:30:55] but you can't do it that way [18:34:07] first row of cb's done [18:34:09] https://www.dropbox.com/s/hvnra318gfjiqg4/Screenshot%202020-06-01%2012.33.38.png?dl=0 [18:34:29] looks great! [18:34:44] thanks [18:34:45] the white dots are not necessarily correct yet [18:35:13] just have to change the texture, which I will do at the end to have the correct ones [19:09:53] :D [19:14:14] hi [19:14:45] hey Jordan [19:20:33] is alex offline? [19:21:36] no he's here, just heads down in Blender probably :P [19:21:37] AlexB_88: [19:22:29] as always :-) [19:23:04] hey Jordan [19:23:11] hi alex [19:23:25] working on circuit breakers this morning [19:24:41] i have repositioning the screws + added some small details in back of the LM [19:25:06] updated texture https://1drv.ms/u/s!ApTRgF_OsQUFgVQ8kCJSPmgbaOH0?e=BOgZsT [19:25:34] updated LM_VC https://1drv.ms/u/s!ApTRgF_OsQUFgVMVuuAacSJsnuEH?e=Gfhu7Q [19:25:56] are you still working with 2.79? [19:27:31] yeah still 2.79 [19:27:44] is that blend file 2.8? thats what works best for me [19:27:59] yes 2.8 [19:28:24] perfect [19:28:35] try it and tell me [19:34:01] looks great [19:34:23] I was dreading thinking of making those ECS rotaries... but looks like you took care of it :D [19:35:42] :-D [19:35:50] that was easy [19:35:55] hey Jordan [19:36:01] hi indy [19:36:16] hmm, I have the same problem as 2.5 years ago. I am confused yet again how LM-1 was oriented in the SLA :D [19:36:46] Im going to finish up everything forward of the step, if you want to continue developing the back some more feel free [19:37:24] I do as much as I can [19:38:15] sounds good, do you have any references for the dimensions etc? [19:38:39] I am using the cross-sections in the systems handbooks as a guide [19:38:56] Unfortunately not. only photos [19:39:45] i use this https://1drv.ms/u/s!ApTRgF_OsQUFgU78AXFhwwXr0E-U?e=UGprpa [19:40:26] ok [19:40:36] https://www.dropbox.com/s/835ssknop0m6ez1/LM_plan.zip?dl=0 [19:40:50] those are screenshots I took from the systems handbook [19:41:03] I use them as background images in blender, really helpful [19:41:04] and i think i can you some pics from here http://spacemodels.nuxit.net/LEM-24/index.htm [19:42:57] I have to run, Ill be back later! [20:36:20] night! [20:54:21] AlexB_88 check this new texture https://1drv.ms/u/s!ApTRgF_OsQUFgVXlrvkVqYtr8SMj?e=knZThU [21:03:37] hmm, I think I like the way it is before better [21:03:39] just grey [21:04:15] if you look at the real photos, the color of the panel is already correct [21:04:16] https://www.hq.nasa.gov/alsj/a16/LM11-co47.jpg [21:04:39] the one you made has a bit of green in it [21:09:24] but the texture is too monotonous. I'll take the color out. [21:10:10] https://1drv.ms/u/s!ApTRgF_OsQUFgVXlrvkVqYtr8SMj?e=oJhTcW [21:14:29] thats better yes, but also the quality of the letters and gauges seems reduced from before, is there a way to adjust that? [21:18:34] that was only for testing. you can still do something. I actually wanted to scale the texture to 4k but there were problems with the display. the letters would be better on 4k. [21:22:57] I see what you mean, it is a bit monotonous but then again I also think thats not totally unrealistic for Apollo panels :D Nonetheless I guess adding a slight rugged feel to it could help, I just think it shouldnt be over done [21:34:17] in reality there are only a few monotonous areas. an old artist said, dirty your pictures, they'll look more alive. [21:35:57] yeah that makes sense of course, I guess its finding a balance [21:36:52] heres a preview of the cb's [21:36:53] https://www.dropbox.com/s/hvnra318gfjiqg4/Screenshot%202020-06-01%2012.33.38.png?dl=0 [21:39:52] looks great [21:40:59] the white stickers at the tip are found only on certain CB's I think it may of varied from mission to mission [21:44:44] oh I have a question for you, I tried exporting the coordinates of my CB's with the include file in blake's exporter [21:45:02] but it just lists the group names, not the vectors [21:45:15] unless I misunderstood its function [21:48:32] https://1drv.ms/u/s!ApTRgF_OsQUFgVaLbWTqtdsePwzh?e=PicG5t [21:48:53] you have to do this for all groups. [21:49:10] ahh, ok [21:49:12] thanks [21:50:21] set hack at include position [21:55:00] works great [21:55:18] (y) [21:55:31] I have like 100 CBs to define so it sure helps :D [21:57:24] if you set it once at one cb and copy that cb it should be set the include flag automatically [21:58:01] i have to leave. its late in germany. good night. [02:33:37] aha! [02:33:48] Sundance does not define STATE as "ERASE +15D" [02:33:51] almost certainly [02:34:04] RRRATE is located inside that [02:35:16] wow, this comment in Luminary [02:35:22] "ALARM 501 DELETED IN DANCE 279 PER PCR 97." [02:35:29] if only everybody left comments like that [04:03:11] Oh but where's the fun in that? What's the point to working on someone else's code if you can't bill 5 hours figuring out what exactly "// FUCK FUCK FUCK FUCK FUCK" was supposed to mean? [04:04:48] (The answer turned out to be "Oh, I must have missed that comment when I copied the code. I made sure to delete all the others.") [13:52:30] hey [13:53:19] Hey Nik [13:57:36] was testing Apollo 5 with docked stages [13:57:40] everything went fine [13:57:45] until [13:57:47] https://i.imgur.com/tbktICd.jpg [13:57:53] hey [13:58:07] haha [13:58:08] that's the LM docked to the CSM/SLA "docking port" [13:58:23] where the nosecone was docked [13:59:45] that's one thing that's new, you have to manage the docking ports, delete them etc. [14:08:05] right [14:08:59] that docking port did get deleted, but the function that creates it was called again just after :D [14:12:22] ah yes, I remember those kinds of issues when we did the LM/SLA docking port [14:13:49] one additional issue, the connector class to send data between docked stages we use has a constant docking port number [14:14:07] so if I delete docking ports then it could cause issues [14:14:26] might have to write a function that disconnects them all and reconnects them correctly again [14:56:08] ... which is not possible [15:17:23] surprising [15:17:37] doesnt sound all that complicated [15:21:47] well it is possible, but I have to write some new code for the connector class itself [15:22:09] not really something I wanted to do [15:23:33] ah I see [15:24:11] finishing up panel 12 CBs on my end [15:24:16] ugh [15:24:19] *panel 16 [15:27:30] great [16:51:48] morning! [16:54:52] next up in Sundance tonight is the landing radar code [16:55:03] curious to see what that is going to look like :D [17:49:39] hey Mike [17:49:48] well they did test the LR on Apollo 9 [17:49:54] so it shouldn't be too broken [17:51:15] ah good :) [17:53:17] spurious test at least [17:58:35] there was enough LR testing on Apollo 9 that they made an anomaly report :D [17:59:33] nothing interesting LGC wise though, hardware issues [18:01:34] made to LM sep on Apollo 5 in my docked stages branch, but then ran into docking port issues. Have to fix some stuff there, but then, I think, Apollo 5 works properly [18:01:38] made it* [18:02:32] awesome! [18:03:56] aerodynamics and docking ports for stage connections, that's the two challenges of doing it that way [18:04:35] next I have to make it so the S-IB and S-IVB stages work normally again when they get separated from the Saturn class [18:04:47] and then I can remove all that stupid LEMSaturn code I had to implement [18:05:17] I guess that's the goal for now. Apollo 5 properly working with stages docked to each other, other missions not being horribly broken from that update [18:10:39] sounds excellent [18:12:11] I'd prefer to have IU and SLA as separate vehicles as well. Maybe when Alex has a free minute he can separately save those parts of the S-IVB mesh [18:13:52] but I wouldn't want to untangle S-IVB, IU and SLA code right now. Maybe later [20:44:26] indy91, quick question [20:45:10] I am doing the thumbwheel switches on panel 12 (volume thumbwheels) [20:45:38] this is what I have in the RedrawVC function I added to ThumbwheelSwitch class [20:45:43] OurVessel->SetAnimation(anim, state / maxState); [20:46:45] it doesnt seem to work though, the weird thing is if I set the state with direct value like (anim, 0.5); the animation works [20:47:00] so I know the function is working [20:47:12] its just the state / MaxState that doesnt [20:47:28] state is 0-9 and maxState is 9 [20:47:46] so state divided by MaxState should always be in the range 0-1 [20:48:06] any ideas? [20:54:51] ah [20:54:58] probably because they are both int [21:02:16] fixed it [21:02:23] double s = (state * 1.0) / (maxState * 1.0); [21:02:24] OurVessel->SetAnimation(anim, s); [21:02:33] ah [21:02:40] was just looking at your messages :D [21:02:55] no prob :D [21:03:00] I think what the *1.0 does is convert it to double [21:03:13] yeah [21:03:45] double s = ((double)state)/((double)maxState); [21:03:58] maybe rather that, but it does the same thing [21:04:18] right, it does look cleaner so I think Ill use that [21:07:26] good night! [01:54:35] okay cool, Sundance 302 has R04FLAG in the same place Luminary does [01:54:46] the systems handbook shows it sharing with LOSCMFLG [02:27:02] well [02:27:04] I have to say [02:27:19] a lot of this radar code is much closer to Sunburst than it is to Luminary :D [03:48:38] indy91, tomorrow I would like to talk about the missing mystery function at the end of fixed-fixed. I've now disassembled all references to it, and based on what I'm seeing I'm almost 100% convinced that we're not missing any (i.e. I don't think modules b1 or b5 would call it at all) [03:49:00] and because we have all references, maybe we can piece together what all of the things that call it have in common [14:21:28] hey [14:29:34] hey Alex [14:31:38] I'm still confused about the orientation of the LM in the SLA [14:31:43] when I really shouldn't [14:32:00] what is the relative positioning of the CSM and LM hatches? [14:37:56] hmm good question [14:39:21] looks like they are 180 degrees from each other in NASSP [14:39:51] right [14:40:52] I had to use a different docking port orientation in the S-IVB class for my docked stages than we normally use for the LM [14:40:56] and I don't know why... [14:41:10] but I guess the issue has to be somewhere else [14:41:17] not the LM or the SLA/LM docking port [14:47:28] must be S-IB or S-IVB standing wrong on the launchpad? :D [14:47:58] the issue was confusing me enough for a bit that I believe the LM was orientated in a different way in a Saturn IB SLA vs. Saturn V [14:49:52] and I think I am still doing something wrong [14:50:09] the LM DPS-1 had a good direction, but it was off in yaw [14:50:18] samw for the cold soak attitude relative to the sun [15:00:32] might be a unique issue with docked stages [15:00:45] getting every stage to have the right orientation [15:10:15] yeah, you have to be careful with the orientation in the scenario of each docked vessel [15:10:21] I think the nosecap was doing something bad [15:10:30] didn't cause IU alignment issues interestingly [16:48:56] morning! [17:08:49] hey Mike [17:09:43] what's up? [17:10:14] I just realized that I might never have aligned the clock correctly when launching Apollo 5 [17:10:29] like, ever [17:11:19] O_o [17:11:24] interesting, lol [17:11:25] how so? [17:11:36] Sunburst treats that a bit differently, but it's likely the cause of e.g. not aligning the LM right to the Sun during cold soak [17:11:58] well, Sunburst expects TEPHEM to be midnight before launch [17:12:03] and clock counting up from that time [17:12:07] pretty standard [17:12:25] but it does not seem to update TEPHEM at launch [17:12:49] rather stores the liftoff time in TPRELTER [17:13:33] Apollo 5 launched at 22:48 GMT [17:13:57] clock zero is probably around 22:00 when I activate LM-1 in a T-1 hour scenario [17:14:20] so I probably got lucky that I am only off 2 hours from midnight [17:14:54] lacking a proper REFSMMAT having a wrong launch time like that sounds worse than it is [17:15:14] but I am sure it will align much better to the Sun if I give it a prelaunch clock update [17:16:22] in the CSM we automatically update the time registers in the AGC at AGC turn on [17:16:33] we don't do that in the LM [17:16:41] maybe that's why I never thought of checking that :D [17:16:54] because this is your usual AGC sitting active on the launchpad [17:16:56] :D [17:18:11] hahaha [17:18:25] very interesting [17:21:02] hmm [17:21:10] I can't use the usual clock update [17:21:24] that would just cause it to count up to T+0 [17:21:31] instead of from midnight [17:24:20] could this also be why we were tumbling on the last burn? [17:24:45] or was it just burning in the complete wrong direction [17:24:50] I remember something not working there [17:26:37] I think that was a padload issue [17:26:47] I forgot to update something in the T-60s scenario [17:27:11] which I had updated in the T-1 hour scenario, the baseline scenario [17:27:50] gotcha [17:28:27] so while I try to get the right clock update working [17:28:36] let's talk about Sundance [17:29:25] also, no separate noun table part in the Sunburst listing, how rude. Making me search for the nouns... [17:40:20] hehehe [17:40:29] I'm doing an operations rehearsal right now [17:40:33] let's talk Sundance in a bit :) [17:40:55] surew [18:25:11] okay, all done [18:35:38] still learning how to update the clock in Sunburst [18:35:50] but we can talk Sundance for a bit [18:37:06] cool [18:37:09] so, mystery function [18:38:08] yes [18:38:19] it's called immediately upon entering V45 (which is V67 in Luminary) [18:39:19] it's called in V83, but only after a big interpretive chunk. the call is just before MARKBRAN, so when it goes to set up displays [18:40:05] it's called as the first thing in R32 (P76 in Luminary) [18:40:41] the Systems Handbook doesn't even have the V45 [18:40:57] it's called at the beginning of V48 [18:41:21] and interestingly, it's called in two places in V82 [18:41:42] both times immediately before putting up a V16N44 display [18:42:25] and that's it [18:42:34] do those stand out as having anything in common to you? [18:44:24] if anything is that it is display related [18:45:03] yeah... extended verb displays [18:45:32] some priority thing [18:45:47] something preventing program alarms [18:46:11] due to overloading [18:48:39] in the GSOP, the first block of R32 is "Inhibit Rendezvous Navigation Data Processing" [18:49:12] that could be related to V45, 82 and 83 [18:49:44] so how much do you know about the mystery function? [18:49:53] what kind of operations does it [18:53:02] could it prevent 06 49 displays? [18:53:14] I only know where it is and how many instructions it is [18:53:30] hmm [18:54:27] https://github.com/thewonderidiot/sundance/blob/master/b2_302.disagc#L6145 [18:54:38] there's the beginning of R32 [18:55:50] UNK7766 is the mystery function? [18:55:52] yep [18:58:54] GOMARKF ; GOFLASH in Luminary. [18:59:03] maybe another hint that it is somehow related to marks [19:00:56] yeah, I think you're right [19:01:15] where in the GSOP do you see the "Inhibit Rendezvous Navigation Data Processing" block? [19:01:40] PDF page 277 [19:01:49] section 5 of course [19:02:47] hmm, interesting [19:04:51] I wonder if it has to do with OPTIONX and N12 not existing [19:05:48] no option codes? [19:06:47] everything that uses N12 in Luminary used N06 in Sundance [19:07:05] ah [19:07:07] they split them apart because overlapping displays could try to use the same erasables to display different things [19:08:17] that happened in Luminary 31, and Colossus 221 or so [19:08:54] right around when they would have been working on Sundance 302 [19:09:51] ah, Colossus 220 [19:10:19] "The new variable OPTIONX was added for the new option code needed in extended verbs. This was added to prevent the erasable conflict caused when extended verb 82 with N06 is running on top of a program displaying N06." [19:12:03] ouch, right :D [19:12:35] I don't think R32 has any option codes though [19:12:45] ah, darn [19:20:16] can you explain again why we don't have the mystery routine anywhere? Was it added after Sundance 292 and is in a rope module we don't have? [19:21:00] yep, exactly [19:21:10] we only have rev 292 of B1, and it was added to the end of bank 2 [19:21:40] oh wait, there's one more potentially very helpful piece of information I have about it [19:22:04] I can tell you the range of page numbers it could have been defined on, to a somewhat narrow window [19:22:17] so we can narrow it down to a few log sections [19:24:38] page in the listing? [19:24:43] yeah [19:24:50] so going off of Luminary 69 page numbers [19:25:03] and that helps... how? :D [19:25:21] by knowing where it is defined, we might get context for what it is [19:25:33] hmm, ok [19:25:43] for example, if it could only have possibly been defined on DAP pages, then we would know it is DAP related [19:25:50] I thought it was squeezed in some empty spot at the end of the bank, so would be unrelated to stuff around it [19:26:00] in memory yes [19:26:10] oh, right, I get it [19:26:23] but the order of stuff in memory is defined by the order in the listing -- i.e., the log section [19:27:11] so the absolute earliest it could have been defined is on page 1368, after DOWNENT2: https://archive.org/stream/luminary6900miti#page/1368/mode/1up [19:28:29] and the absolute latest is on page 1453, before MAKERUPT: https://archive.org/stream/luminary6900miti#page/1453/mode/1up [19:28:52] so it must be somewhere in those 86 pages [19:30:16] log sections SERVICE ROUTINES, ALARM AND ABORT, UPDATE PROGRAM, RTB OP CODES, T6-RUPT PROGRAMS, DAP INTERFACE SUBROUTINES, DAPIDLER PROGRAM, P-AXIS RCS AUTOPILOT, and Q,R-AXES RCS AUTOPILOT [19:30:28] ...an interesting mix [19:30:33] yeah [19:32:43] I doubt it is DAP related [19:32:53] me too [19:32:56] just doesn't make sense considering where the function is all called [19:33:01] update program is interesting [19:35:00] also seems unlikely? [19:35:59] I bet it's right at the end of SERVICE ROUTINES [19:36:33] right next to this: [19:36:35] # B5OFF ZERO BIT 5 OF EXTVBACT, WHICH IS SET BY TESTXACT. [19:36:36] # MAY BE USED AS NEEDED BY ANY EXTENDED VERB WHICH HAS DONE TESTXACT [19:36:52] that seems pretty closely related [19:37:32] yeah [19:37:48] does Sundance have B5OFF? [19:37:52] yep [19:38:53] that does indeed sound related [19:39:51] hm [19:39:55] it's 6 instructions long [19:39:58] one clearly has to be TC Q [19:42:25] also, *something* changed in Luminary such that this was not necessary there [19:44:12] I wish we had Margaret's documentation for the display interface routines [19:50:02] nice Luminary 69 video btw [19:50:11] I think I'll make one myself [19:50:23] from PDI to when it runs out of fuel in P71 [19:51:05] we probably knew that before, but as Luminary 69 doesn't compensate for any DPS lags or guidance cycles there also are no throttle oscillations at all in P66 [19:51:10] nice! that would be cool :D [19:51:27] oh interesting [20:14:47] Sunburst's clock update method is not very... intuitive [20:20:39] haha [20:21:37] V55 update is in centi seconds [20:21:45] so you can do 999.99 max [20:21:52] not even that [20:21:54] it's octal [20:22:06] N65 shows hours in R1 and seconds R2 [20:22:09] both are TIME2 [20:22:17] just scaled, or truncated [20:27:13] oh man [20:27:40] N65 hours are fractional right? [20:27:42] XXX.XX hours [20:27:53] so as the seconds and minutes go up the fraction of the hour increases [20:28:41] yes [20:28:51] and seconds is truncated [20:28:58] 2 hours is being displayed as [20:29:03] R1 +00200 [20:29:14] R2 +200XX [20:29:28] with random centiseconds [20:29:32] a bit like the AEA [20:29:40] oh, V55 isn't octal after all [20:31:11] I think I found a method to do it [20:31:20] just need to automate it for one of the MFDs [20:31:28] right I just have the clock error in a debug string [20:31:31] right now* [20:33:10] I still want to see LM-1 point itself at the sun properly today :D [20:34:31] timing is pretty tight, to get the clock update done in the T-60 seconds scenario [20:34:41] including going to P00 and back to P02 again [20:34:50] ... which I might not even have to do [20:43:05] :D [20:43:07] fingers crossed! [20:44:32] 22 hours (aka -2) hours off in Earth rotation, equals 30° [20:44:46] that sounds about right for the pointing error [20:45:02] I have the angles it should maneuver to from the mission report [20:45:11] when I saw those I was pretty sure something was off [21:07:35] LM X-AXIS NORMAL TO THE ECLIPTIC PLANE AND BISECTOR OF LM +Z/-Y AXES TOWARD THE SUN [21:07:44] https://i.imgur.com/CfOJYLV.png [21:07:58] IMU gimbal angles exactly like in the mission report [21:08:14] nice!! [21:08:15] :D [21:09:58] I'll fly this further tomorrow, but I don't think there will be any big improvements over previous behavior [21:10:10] it's mainly pointing right at the sun, I think [21:11:00] almost everything Sunburst does is in stable member coordinates [21:11:10] and those are fixed at launch, doesn't matter when the launch happens [21:11:53] even coasting integration accuracy will improve, as you define the polar axis in SM coordinates as well [21:15:03] night! [21:15:07] uhh [21:15:21] even coasting integration accuracy won't improve, is what I wanted to say [21:15:29] liftoff time etc. is not used by much [21:15:45] night again! [12:39:05] Weird. Guenter statyed up while my client wouldn't even connect. [12:44:03] usually you go down together :D [14:17:11] hey [14:20:43] hey Alex [14:26:53] sorting out aerodynamics of the docked Saturn IB stages [14:29:23] nice [14:29:42] and Im trying to get my talkback working on panel 12 [14:38:31] my conclusion is still that the docked stages solution is quite workable [14:38:42] some disadvantages, mostly advantages [14:39:12] what I really like is that you can focus on one stage and don't have to worry about the whole Saturn class or what happens with the stage at staging etc. [14:48:22] ah, right [14:49:17] you going to try it with the Saturn V afterwards? [14:49:37] maybe eventually [14:49:56] next big challenge would be a Saturn IB with a CSM [14:50:33] but still a lot to do before I can even be done with Apollo 5 [14:55:34] although I can do do my favourite thing next [14:55:39] delete the LEMSaturn class [14:56:00] should make the LEM dll file a bunch smaller :D [14:56:15] as all those Saturn related files can be removed from the LEM project [16:01:08] panel 12 is now functional [16:01:09] https://www.dropbox.com/s/9p3pdeika25pj9g/Screenshot%202020-06-04%2010.00.30.png?dl=0 [16:01:33] well save for the recorder talkback, which I have to investigate [16:05:31] btw, so far with everything running (which is most of the forward section) including Jordan's added details, I am holding 144 fps [16:05:45] even at 30x, looking at the moon [16:06:00] There should be more that the graphics card is doing with the VC, right? [16:06:15] and what's the issue with the talkback? [16:07:08] yeah, and the very little blitting [16:08:42] about the talkbacks, I am not sure really [16:09:17] on panel 1 and 2 they are working fine? [16:09:29] the recorder talkback is not very functional on the 2D panel so it may be a special case with it [16:09:32] yeah all working [16:10:13] I am going to add the ones on panel 14 above and see if they work [16:10:16] right, it will barely be on [16:13:34] ... [16:13:36] or not at all [16:14:00] if you want to test it [16:14:04] LM_DSEA::CDRVoiceXmit in lm_telecom [16:14:08] only returns false [16:14:13] same for LMP [16:14:23] make one of those return true and try it again [16:16:03] and voice mode ICS/PTT [16:16:27] hmm [16:17:13] I'm not sure how it's supposed to work to be honest :D [16:24:21] All the VC stuff should be done in the GPU while all those bitmap operations for the 2D panels are all CPU work. Great to see the improvement. [16:26:33] yeah, definitely better performance [16:27:56] that being said, my GPU is certainly no lemon [16:28:32] Ill have to se how my laptop's GPU handles it [16:32:59] indy91, yeah right now the 2D panel shows it as always barberpole [16:33:28] the issue in the VC though is that the talkback doesnt draw at all (shows the half-way tb) [16:36:58] ah right [16:37:22] it's a standard IndicatorSwitch [16:38:16] yeah [16:39:30] and you have the oapiVCRegisterArea and the code in clbkVCRedrawEvent [16:40:44] and the oapiVCRegisterArea is PANEL_REDRAW_ALWAYS [16:40:53] yeah [16:41:24] the only difference is I am using a different MainPanelTex [16:41:49] I now have MainPanelTex1 & MainPanelTex2 [16:49:56] ok so the panel 14 talkbacks are working [16:50:24] so its rally just an issue with the tape recorder tb [16:50:28] really* [17:04:54] morning! [17:05:45] only one bank of Sundance 302 left, and then it's just rev 292 of module B5, and the disassembly will be complete :) [17:35:11] hey Mike [17:35:15] it's getting there :D [17:39:00] should hopefully have something for you to try out in the next few weeks [17:39:43] we'll start with a straight frankendance, where the modules as we have them have been patched to work together, with no speculative reconstruction [17:39:54] and then start adding known changes made in 302 and 306 from there [17:42:35] although maybe I'm being too optimistic, I haven't yet seen how bad the descent and ascent programs are [17:42:56] and P10/P11 are going to be a challenge and will probably need your help mapping what's in the GSOP to what I'm seeing in the code [18:04:19] right [18:04:30] well I'll keep my Apollo 9 launch scenario ready [18:04:37] and whatever I will need for P10/P11 [18:05:55] how goes Apollo 5? [18:06:40] oh, a while ago I added mission files, to load mission specific systems etc [18:07:03] and I guess I intended to include the inverted stage verify bit on LM-1 there as well [18:07:10] but I didn't [18:07:26] so I got what I already had when I first flew Apollo 5 [18:07:38] went through all of the DPS-2 burn [18:07:40] fire in the hold [18:07:43] hole* [18:07:48] APS starts up [18:08:04] but it doesn't recognize the staging and stays in P44 forever :D [18:08:11] hahaha [18:08:15] that pesky stage verify bit :D [18:08:21] yeah [18:08:33] and I checked the Systems Handbooks again [18:08:49] on LM-1 it is indeed inverted from later on [18:09:02] even if it barely is used in later LM software I guess [18:09:14] ah, so LM-3 already had it the other way around? [18:09:19] yeah [18:09:27] there is a logic true signal going into the LGC when the descent stage attached [18:09:33] on LM-3 and later [18:09:34] I wonder what LM-2 had [18:09:51] logic true leading to input bit being 0 [18:10:04] and it's the other way around in LM-1 [18:10:35] with descent stage attached it energizes a relay, which opens rather than closes a relay contact [18:11:00] weird that they changed that [18:11:52] yeah [18:12:11] if the wiring fails, the LGC will think the descent stage is attached on LM-1 [18:12:38] I think I like the later wiring more, a bit [18:13:29] I guess that's why they changed it, haha [18:14:54] oh and I just deleted my LEMSaturn class, very happy I could do that, it always was buggy [18:15:06] Saturn IB built around a LM, all one vessel in Orbiter [18:15:16] oh awesome! [18:15:21] bloated the LEM dll file [18:15:30] because I had to add all those IU subsystems to it [18:16:01] so for Apollo 5 at least, I am all in for docked stages [18:19:54] with all the communication issues between departments, especially for the LM, I wouldn't have been surprised if that stage verify thing was a software bug [18:20:13] and nobody telling MIT it is inverted [18:20:29] but the Systems Handbook looks like they got it right [18:20:43] hahaha [18:21:08] we might have enough Grumman drawings to see it there too [18:21:12] that would probably be in an ICD, which should be documented well [18:21:17] oh true [18:21:21] let me look [18:21:29] how the DPS exactly behaves is another story [18:22:22] the source for that information, as mentioned in Luminary memos, is often just phone calls with Grumman [18:23:06] do we have LM-1 specific ICDs? [18:23:48] there's only one ICD, as far as I know, that has LM differences as notes where needed [18:23:56] oh [18:24:30] turns out, LTA-8 had the LM-3 and later configuration for that bit as well [18:24:34] well the CM ICD for that doesn't go much further than the wire going into CMC electronics [18:24:47] yeah, the LGC ICD is much better [18:24:48] http://www.ibiblio.org/apollo/klabs/history/lm-icd/01_control_and_status_sh-8.pdf [18:24:52] pages 6 and 7 [18:25:25] aha [18:25:27] LM-1 only [18:25:40] and a separate LM-2 only on the next page [18:25:55] oh fascinating, I didn't notice that [18:26:11] and then "LTA-8, LM-3, & sub" [18:26:44] LM-2's configuration looks pretty crazy compared to the others lol [18:27:04] for LM-3 and so on, those two contacts are for GSE test relays [18:27:31] I think that's what they are supposed to mean [18:27:53] GSE can energize relays to test the bit [18:28:44] ah, that makes sense [18:28:55] but I guess that confirms it [18:29:03] LM-1 has that relay powered [18:29:19] and the normally closed contact will be open whenever the descent stage and power is on [18:30:05] LM-2 is more complicated, but the logic seems like LM-1, do you see that as well? [18:30:25] relays being normally powered with the descent stage on [18:30:29] opening contacts [18:32:53] just with redundant power I guess [18:32:58] for relays 3/4 and 5/6 [18:33:04] probably CDR and LMP buses [18:44:24] yep makes sense [19:10:12] one thing I need to figure out yet is mission time in the stages. Right now I have to give most stages a mission time for things to work correctly. [19:10:19] Hopefully I can make it more flexible [19:10:34] also so that we can have actual launch holds and later launches [19:25:59] KSP 2 is dead, Take 2 told the developer's employees they had to quit and hire directly with Take 2, and when they didn't go for it Take 2 killed them. [19:26:17] then tried to threaten them afterward. [19:26:27] https://www.bloomberg.com/news/articles/2020-06-03/kerbal-space-program-2-release-disrupted-by-corporate-strife [19:27:43] oh boy [19:34:31] Guenter, I think Bloomberg has you figured out [19:35:06] yeah, that's too bad [19:35:20] the cycle of KSP development hell seems like it will never end [19:35:53] It's been officially delayed to fall of next year but chances are T2 will kill it before it releases because it's going to be poison now. [20:23:22] night! [05:14:57] indy91, I've made it up to S40.8, cross-product steering [05:15:03] and it has a ton more code than luminary [05:15:13] in particular.... it appears to actually have the cross-product steering [05:15:19] going off of the GSOP [05:15:26] Luminary doesn't have the bulk of this [14:55:03] hey [14:58:59] hey Alex [14:59:22] doing the fixes to the S-IB and S-IVB stages so that they still work when created and separated from the Saturn class [15:05:39] nice [15:06:13] did you get that TB working? [15:11:17] no, I have left it commented for now [15:11:27] I think the system itself needs more developping [15:13:25] for talkbacks? [15:15:00] talkbacks are working in the VC, there is no issue with that [15:15:22] its specifically the tape recorder talkback that is not working [15:15:52] even in the 2D panel, that talkback doesnt do anything [15:16:26] so I am thinking that system is not developed enough to provide proper tb operation [15:16:37] right, but I thought the issue was that specific TB wasn't even being drawn in the VC [15:16:41] showing the halfway state of it [15:17:03] yeah that is true, I guess it should at least draw it [15:18:51] do you have the code up on Github? [15:19:01] maybe I can take a look, maybe I see something what would cause it [15:19:10] yes, I pushed the latest last night [15:19:12] to LMVC [15:19:21] ok [15:19:22] the code is commented but its there [15:20:30] https://github.com/jalexb88/NASSP/commit/6d919d44541bb73931dde1b2afc3e8e0d33e38f2#diff-c1009e3937fed4229754ab2b1a721736R1389 [15:21:25] line 1389 LMVC.cpp [15:22:00] which calls the DrawSwitchVC function in IncicatorSwitch [15:22:24] battery talkbacks are working fine? [15:22:50] yes [15:24:33] SURFHANDLE MainPanelTex2 = oapiGetTextureHandle(hLMVC, 8); [15:24:38] which texture file is that loading? [15:24:56] the 2nd VC panel texture [15:25:14] I have panel 8,11,12,14,16 on that one [15:25:46] so LMVC_2.dds [15:35:38] yeah I'm not seeing the problem [15:35:39] would have to switch branches [15:39:15] have you tried the new LM views yet? [15:41:47] oh, are they already merged? [15:42:14] yeah [15:42:27] a few commits ago [15:42:49] in LMVC [15:43:09] so not in Orbiter2016 [15:43:15] o not yet [15:43:19] no* [15:43:44] sorry, I guess you meant merged in Orbiter2016 :D [15:44:55] ah ok, have to commit my Apollo5 updates first before I can check the LMVC branch [15:50:43] ok sounds good [15:50:51] time to do panel 8 [16:29:32] morning! [16:33:35] hey Mike [16:33:53] hey [16:34:04] so, cross product steering, S40.8 [16:34:16] tell me what you know about that :) [16:34:24] ah right, I wanted to look at the Sundance GSOP [16:34:32] let me do that first [16:39:36] well I guess Luminary has a lot of the calculations outsourced to FINDCDUW [16:39:52] yeah [16:42:05] a whole lot, lol [16:43:00] S40.8 is about 3 times as big in Sundance as it is in Luminary [16:43:22] makes sense [16:43:29] I bet FINDCDUW isn't small either [16:44:10] one thing that I'm seeing in the code that I'm not seeing in the GSOP [16:44:46] is the cross product is being divided by pi [16:45:05] oh that could be the choice of the scaling [16:45:12] LVDC uses pirads most of the time for angles [16:45:33] so in the EDD there are a few random PIs that we don't use in our version [16:45:54] ohhhh interesting [16:48:22] cool [16:48:28] I think I have it mostly figured out then [16:48:35] just need to come up with names for things [16:53:03] also need to figure out what the scaling for these constants actually is [16:53:44] the exhaust velocity that they use is clearly notional, lol [16:54:08] octal 17000 00000 -- which is 60 B-7 [16:54:18] something tells me a real value would be nowhere near that round :P [16:54:19] haha [16:55:25] or maybe it is [16:55:38] Sundance uses 3000 m/s exhaust velocity for both DPS and APS [16:56:04] oh! really? [16:56:06] okay [16:56:48] MIT and the LM propulsion people [16:57:06] something didn't go right between those :D [16:57:10] lol [16:57:45] the estimates aren't too bad [16:58:03] Luminary 1 C 2955.889 for the DPS and 3030.3216 for the APS [16:58:47] it's used in the time-to-go calculation [16:58:59] so only for quite long burntime remaining that will lead to an error [17:00:50] I'm looking at FINDCDUW and try to figure out if that can even be called cross product steering lol [17:01:38] but yeah, in sundance the PI factor definitely makes sense, as it converts to an angle difference [17:04:27] it's similiarly used in the LVDC; when it calculates guidance commands (angles) from two steering factors [17:05:09] basically a conversion from no unit to pirads [17:05:22] if it was rads that wouldn't be necessary [17:07:04] I have to be careful with that when using the EDD :D [17:07:23] similarly it also uses 0.5 and 1 in place of 90° and 180° sometimes [17:07:29] also need to be careful there [17:16:18] hmmm okay yeah that makes sense [17:16:42] and yeah, I couldn't find anything that even remotely resembles cross-product steering in Luminary [17:16:55] I think it's silly that they continued to call S40.8 the "cross product steering routine" :P [17:17:17] I'll work on scaling tonight [17:17:39] this little surprise chunk of interpretive code will be good practice for P10/P11, which are right around the corner [17:18:22] yeah, not only does S40.8 itself not do that cross product anymore [17:18:36] even the combination of FINDCDUW and DAP work somewhat different [17:28:37] man Sundance is such a cool program [17:29:03] so many interesting things in here [17:30:35] yeah [17:31:06] P10/P11 are just one of many things haha [17:33:07] I recorded the Luminary69 landing video today, haven't done any editing yet though [17:33:17] landing and half an ascent [17:33:40] with the scenario I had prepared for the case you wanted to show it with the real AGC :D [17:34:55] nice! :D [17:35:26] had forgotten to close some CBs for the APS in that scenario [17:35:41] might have been awkward if you wanted to try and deomstrate your usual abort stage [17:35:59] haha oh no [18:49:35] hmm, one good reason to have the SLA as a separate vessel is that AS-203 didn't even fly a SLA [18:49:48] it was just a larger nosecone, different from the Apollo 5 one [18:50:55] right [18:52:50] it wouldn't make this docking port management any easier though [18:53:26] SLA would still need connections to S-IVB/IU, the payload (LM, docking module, etc.) and the vehicle on top (CSM or nosecone) [20:30:58] night! [15:52:16] hey [15:57:31] hey Alex [16:09:24] our IU can use a theodolite no [16:09:25] now [16:10:34] meaning that the LV IMU can have a correct initial attitude even if the vehicle is slightly tilted or rotated [16:11:30] oh nice [16:12:20] so if you accidentally fire a thruster before liftoff, it wont throw off your LV IMU [16:12:34] yep [16:13:01] not that I've seen any launch during testing where it is too far off [16:13:10] 0.02° for Apollo 7 [16:13:17] even less for LC-39 [16:14:06] was just a test to see how off my Apollo 5 with docked stages is [16:14:20] but then I implement it properly for Saturn IB and V LVDC [16:15:09] don't see any downside to it [16:15:24] works reliably [16:15:56] well I hope I haven't confused Y and Z axis [16:16:00] both are always close to 0 [16:26:10] hmm [16:26:21] and I'm seeing a potential bug in the boost navigation [16:26:43] could this be the one that makes LVDC navigation super accurate? It's possible [16:29:36] hmm, doesn't look like it [17:25:17] since I started using the latest DX9 client I have weird graphic bugs [17:26:24] https://i.imgur.com/PLxOkro.png [17:26:26] like this [17:26:33] self shadow issues maybe? [17:28:20] hmm, I used to have that with older versions of the DX9 client [17:28:49] also, the LRV mesh caused issues on the moon [17:29:11] maybe there is a mesh somewhere in the saturn that is causing this [17:32:17] and somehow I now made Saturn V boost navigation less accurate [17:32:37] earlier I had an insertion with 25 meters accuracy on Apollo 5 :D [17:38:18] morning! [17:38:23] wow, that's pretty impressive haha [17:38:54] hey [17:39:41] yeah, the normal errors from integration and higher gravity harmonics should already be more than 25 meters haha [17:40:15] reliably better than 100 meters should be the goal, but something is still off, sometimes [17:41:29] hmm [17:41:46] just changed something back and now it's better [17:41:58] waiting till insertion to properly judge it [17:43:04] basically, in the boost integration a new position vector is calculated from current velocity and gravity. Then, using the updated radius from the new position vector, the gravity terms are calculated for the new velocity vector [17:43:20] I thought that was wrong [17:43:35] the EDD doesn't really give an order for the equations, but kind of indication it should do all those calculations with the old radius [17:43:48] but I guess that is correct and we did have it correct before [17:43:57] that is probably what I had just made worse, temporarily :D [17:45:38] numbers speak for themselves [17:45:41] 10x better [17:50:04] nice :D [17:53:50] a bit above 100 meters off after insertion. I think we basically had that before [17:54:07] there is a lot of sign weirdness with the navigation equations [17:56:17] I believe it [18:04:39] any progress with Sundance? [18:05:04] is the cross product steering routine consistent between different revisions? [18:05:16] we only have the 302 version of Sundance [18:05:28] er [18:05:33] cross product steering [18:05:34] lol [18:05:53] I would take a complete 302 any day :D [18:06:41] but, we have a lot of addresses in this bank for Sundance 306, and they all match up with 302 [18:06:49] so presumably nothing big was changed here [18:06:56] do we only have B3 twice? [18:07:03] yep [18:07:30] ah, I thought we had more of them twice [18:07:32] we got really lucky, only 7 sundance modules but we managed to cover all 6 [18:07:33] nope [18:07:50] well the other modules must be out there as well [18:07:57] somewhere! [18:08:20] I'm like 80% of the way through bank 27, which is the last bank in module B4 [18:08:36] then it's back to rev 292, and the start of the most challenging part of this [18:08:43] the very first thing in bank 30 is P12 [18:09:52] also a fun thing to try if it works [18:10:24] out of curiosity -- what all programs were actually used during the mission? [18:10:44] Apollo 9? [18:11:00] yeah [18:11:26] mission report has a list [18:11:50] P00, P06, P27, P30, P32, P33, P34, P35, P40, P41, P42, P47 [18:11:58] which already can't be true [18:12:03] P52??? [18:12:49] flight definitely has a P52 [18:12:53] flight plan* [18:13:34] and the mission report has a platfor alignment summary [18:13:38] platform* [18:13:44] so that list is already not trustworthy [18:14:18] also P20 concurrent with P32-P35 [18:14:33] haha [18:15:25] maybe I will do this module out of order [18:15:35] the P30s are in banks 34 and 35 [18:15:59] but that should be about it for programs [18:16:07] unless there is a random P21 or so [18:17:16] the P30s will have some differences to Luminary, but not too many [18:17:37] cool, yeah, I'll do that then [18:18:02] try to have as many erasables and things defined as possible before I get into the potentially very different stuff [18:18:13] ah right [18:58:16] alright, back to disassembly, let's finish off rev 302 :D [19:01:03] AlexB_88, it was self shadows, changed some settings there and the graphic issues went away [19:13:10] ah great [19:28:21] hmmm [19:28:27] random constant defined here with no obvious references [19:28:40] 0.762063045 [19:28:46] no idea on scaling [19:28:49] does that look like anything? [19:28:50] haha [19:30:04] uhh [19:30:18] it might look like something to me if it was scaled right :D [19:30:48] I can try randomly multiplying it by 2 until it looks good [19:30:59] in what section is that [19:31:35] CALCTPER / CALCTFF [19:31:39] oh [19:34:31] doesn't really look like anything that is in the GSOP [19:34:40] haha alright [19:34:45] maybe I'll find some reference to it [19:34:48] not many numbers there, 2^-22 [19:35:41] 2^28 - 1 [19:35:49] both don't seem right [19:36:16] here, I just finished the module [19:36:25] ooooh [19:36:27] I have it [19:36:31] https://github.com/thewonderidiot/sundance/blob/master/b4_302.disagc#L6775 [19:36:32] oh? [19:36:38] randomly multiplying with 2 did the trick [19:36:46] 4x [19:36:49] is 3.048 [19:37:01] feet to meters [19:37:01] which is... [19:37:03] oh! [19:37:08] interesting [19:37:19] that constant is 3.04825218 to be exact [19:37:37] which is not quite right [19:37:40] what's the octal? [19:37:55] 30305 24405 [19:38:29] your exact number is 30305 24004 [19:38:33] so that's totally it [19:38:38] they rounded it up somewhere in there [19:39:01] oh just [19:39:01] yeah [19:39:08] 3.04825219 B-2 [19:39:12] looks like it gives me the right thing [19:39:36] yes [19:39:44] nice! [19:39:56] I'm going to have to ask you about some more random constants that I haven't been able to figure out :D [19:40:01] which is not exactly 3.048 [19:40:03] but close [19:40:50] is that in CALCTPER / CALCTFF proper, or in R-30? [19:41:04] it's defined at the end of the bank [19:41:04] https://github.com/thewonderidiot/sundance/blob/master/b4_302.disagc#L6775 [19:41:08] ah [19:41:14] next to a bunch of other constants used by those [19:41:21] but that doesn't necessarily mean anything [19:41:26] probably to convert 35000 ft for the Moon and 300000 ft for the Earth [19:42:08] if you are above those and your orbit takes you below them, then it will display the time to those altitudes [19:42:14] that's the TFF [19:42:50] I'm surprised that's not in Luminary [19:43:01] maybe in controlled constants? [19:43:51] I don't see the octals anywhere, in any program [19:43:56] maybe with a different scaling or something [19:45:44] they do the sensible thing and have it in metric already [19:45:47] in Luminary [19:45:58] MINPERM and MINPERE [19:46:06] that's in R30 [19:46:13] did you get to those in Sundance yet? [19:46:19] yes [19:46:22] hmm [19:46:37] so this is probably just some old constant that they cleaned out when looking for words to save [19:46:42] maybe that feet/meters conversion factor is used for something else then [19:46:46] or not used :) [19:46:47] maybe [19:46:58] on MINPERM and MINPERE, there is something interesting there [19:47:08] both are scaled B-29 in Sundance [19:47:13] MINPERM is scaled B-27 in Luminary [19:47:53] clearly because of the different scalings of the state vector in Earth and Moon orbit [19:48:02] but Sundance should be lunar orbit compatible... [19:48:54] maybe R30 will not work properly then in Sundance [19:48:56] we will see [19:49:02] in lunar orbit that is [19:50:52] hehehe [19:52:45] oh, dumb me, 1 ft = 0.3048 meters [19:52:54] but it could still be right I guess [19:53:16] I just saw those 3048 after each other and thought that must be it [19:53:59] O_o [19:54:47] not? :D [19:56:38] haha [19:57:41] they have a lot of precision in there [19:57:53] for not exactly the right number [19:57:55] if that's it lol [19:58:25] yeah... [19:58:30] so maybe conincidence [20:01:45] uh oh [20:01:59] I'm 25 words into bank 34, in S30.1, and already am hitting major differences [20:02:00] lol [20:03:59] P30 looks quite like Luminary... after the GSOP update from 12-12-68 [20:04:06] big black bars on the right :D [20:04:26] uh oh [20:04:38] uhhh [20:05:07] would they have completely rewritten it between 292 and 306? [20:05:32] no idea, but I think there were definitely a bunch of late changes [20:05:37] damn [20:07:24] the only references I have to bank 34 are from module b1, also rev 292 [20:07:45] so I can't see changes from shifts [20:09:50] what page are you looking at? [20:10:02] 117 [20:11:51] hmm [20:11:55] where does S30.1 fall into that... [20:13:12] actually the differences mostly seem to be related to scaling/limiting HAPO and HPER for display [20:13:14] oh is S30.1 just calculating the HA, HP, DV display? [20:13:57] it does DELVSIN calculation [20:14:04] uhh [20:14:12] maybe [20:15:09] oh that page has a PCR number [20:15:10] 657 [20:15:15] do we know anything about that... [20:15:48] lol [20:15:53] "Sundance GSOP Section 5 Update" [20:15:56] great [20:16:15] very helpful, thanks MIT [20:16:15] already checked that, got equally disappointed [20:16:37] if you see PCR 414 expect the same disappointment [20:16:41] haha [20:16:50] just from revision 1 of the GSOP [20:16:53] 657 is revision 2 [20:16:59] which does say a little bit [20:17:02] but not much [20:17:17] alright well if it's mostly display stuff I'm not too worried [20:17:28] I'll keep an eye out for those computations by the black bars [20:17:39] GSOP section 4 has two PCRs for P30 [20:17:46] well PCN [20:17:50] "PCN-MIT-56" [20:17:57] PCN 401.3 [20:31:55] hi [20:37:21] hey [20:44:14] AlexB_88 https://1drv.ms/u/s!ApTRgF_OsQUFgVivweM_qXO9LoFd?e=hhMoJw https://1drv.ms/u/s!ApTRgF_OsQUFgVcChnFMNw4lHkEV?e=Xjav9y [20:46:27] very nice! [20:46:45] Alex i work on the LM interior but it is a time consuming process. The technical drawings are not 100% suitable for the original LM photos. I will probably need a lot of time to achieve a good result. [20:48:28] right I imagine it will be a while [20:49:06] I am finishing up panel 8 today [20:49:25] I have finished all of panel 11,12,14,16 a;ready [20:49:34] already* [20:56:36] Yes. I will finish part by part. Is the best way i think. [20:57:30] sounds good, no rush [21:12:53] Hi all, [21:13:15] hi [21:14:23] Posted on the forum that I've uploaded my NASSP proceeding on https://github.com/ggalfi/NASSP . [21:16:06] But the post is not appeared for somewhat reason. I guess it was my second post, so it may wait for some admin confirmation [21:18:37] If anyone of you is interested, the branch agcio contains the interesting part. [21:20:32] hey ggalfi! let me approve your post real quick [21:21:16] there we go, that should do it [21:25:52] Thanks a lot! In the post I've collected the vital infos about of my development, but if you have any question I'm happy to answer. [21:30:07] awesome, I'll take a look [21:30:15] you missed indy91 by 14 minutes, haha [21:34:42] Yes I'm on vacation, so I have the opportunity to do this IRCing after the kids went to bed :) [21:35:30] hehehe [21:47:34] hmm [21:47:43] are you accounting for the voltage difference? [21:48:14] between the PGNCS reference and the ATCA reference? [21:56:32] If you mean in CDU the reference signal with 800cps, the answer is "yes, to some extent". I have simulated not the voltage difference, but a possible phase shift. To be precise there are two possibilities: 0 degree shift (normal behaviour) or 90 degree shift (erroneous and worst case behaviour). The flg_phase_bug used to select between the options. [21:59:13] To have other phase shifts (e.g. 85 degrees) I considered but not yet implemented as it would require a bit more complicated calculation in runtime which I tried to avoid to have an enjoyable performance. [21:59:44] it's more than just a phase shift though [21:59:58] the PGNCS reference was 28V, while the ATCA reference was 15V [22:00:06] which changes the sum in the coarse system quite a bit [22:01:43] (when not in LGC, the voltages coming off of the RR resolvers would be derived from 15V, while the coarse system would still add the PGNCS 28V if any ladder switches are closed) [22:01:59] so even at 0 phase you have problems [22:11:37] Oh I see. I calculated everywhere with the same voltage (regarding the calculations the absolute size of the voltages was irrelevant, what I've seen in one of the documentations the after a bunch of transformers it had 4Vrms). However it wouldn't be difficult to take this voltage difference into account, if you look at the relevant part in cdu.cpp [22:11:37] the way how the amplitude of the ladder output is calculated, you can see csa = csa + iceptcoarse and csa = sqrt(csa*csa + iceptcoarse*iceptcoarse) for the 0 and 90 degrees phase shift. And iceptcoarse is the contribution due the reference voltage. So if we adjust it with a factor of (15/28) in case of ATCA feed, we will have simulation for this [22:11:38] voltage difference. [22:12:39] I mean "reference signal" instead of "reference voltage". [22:18:44] hmm, okay [22:19:03] definitely worth trying, I'm curious if it changes your simulation results [22:20:01] in my models generally 90 degrees was too much, and the CDU tended to settle on a single (wrong) angle instead of going manic [22:22:28] Surely you know this webpage: https://www.doneyles.com/LM/Tales.html I got most of the ideas from here regarding how to simulate this 1201/1202 stuff. And on this page on Fig 7. it says that both the ATCA and LGC has a 28V output reference signal. I'm not an electrical engineer and Don Eyles is also a software guy, but I have to ask that are you [22:22:28] sure in this voltage difference? [22:23:08] yeah, hold on [22:24:27] here's a memo from Grumman in which they discovered this issue while testing LM-3 in 1968: https://www.ibiblio.org/apollo/Documents/Memo-GAEC_LMO_541_108_text.pdf [22:24:56] pdf page 12, TDR #15 [22:25:32] "In the LGC mode the resolvers are excited with the PGNS 28VRMS, 800Hz signal. However, in the Auto Track mode the resolvers are excited with 15VRMS, 800Hz from ATCA." [22:28:38] it's also shown in the LM systems handbooks [22:28:43] https://www.ibiblio.org/apollo/Documents/HSI-208818.pdf [22:28:46] pdf page 196 [22:28:58] quadrant G6 [22:29:46] shows the 18V to 15V stepdown transformer within the Servo Amplifier Assembly that generates the 15V and passes it through the RR mode switch to go out to the resolvers [22:32:28] and it's referred to in this memo after the fact, although the exact voltage isn't explicitly stated: [22:32:29] https://www.ibiblio.org/apollo/Documents/Memo-Tillman690731_text.pdf [22:32:33] pdf page 5 [22:33:11] "In SLEW or AUTO, however, they receive this reference from the ATCA. This voltage is frequency controlled by the Primary System through its control of the PCMTEA, but it is *not* phase controlled nor is it of the same magnitude wave form." [22:33:15] Yes I tend to believe to this documents, the memo is practically conclusive as they put emphasize on this difference as a cause of some error. And LM3 was on Apollo 9 so I don't think they changed this till Apollo11. So I think we may safely assume that this voltage difference. [22:33:42] yeah [22:33:53] the phase issue is very well reported but there aren't many sources that talk about the voltage difference [22:35:15] you'll have to adjust the fine system output too -- since the fine system only operates on resolvers, without folding in a reference voltage, its output magnitude is a factor of 15/28 smaller too [22:46:04] Yes, you are right, this difference is lessens the sensitivity of the fine systems. Seem to me if we adjust the Main Summing Amplifier output with the same factor as before (15/26) we will have correct simulation of this. [22:59:16] On the effect of the voltage difference: I think in case of extreme phase shift it is not very important, because then the main problem that the reference voltage cannot cancel out the resolvers contribution (it can only increase the amplitude). That causes a continuous oscillation in the read counter (as far as I remember in simulation it was [22:59:16] circa 10 degrees). However the voltage difference will cause a constant bias in the angle measurement, so it will lead to erroneous measurements (which isn't good) but not lead to oscillation (which makes life a bit easier). [23:03:00] In case of smaller phase shift it is also true, the amount of the error is dominated by the voltage difference, but it not generates a deluge of increment-decrement signals. [23:03:15] yeah [23:03:31] the problem with extreme phase shift is the sampling timing in the digital portion in the CDU [23:08:33] Anyway I'll put this adjusments in the code, and test whether it causes any significant difference. But only tomorrow evening as I am very far from any Visual Studio at the moment. Though it was a pretty interesting find, thanks! [23:09:12] sure thing! I'm happy to have somebody to talk to about this, haha [23:09:30] I too have spent many hours staring at CDU schematics trying to figure out exactly how it misbehaved :) [23:10:22] heres what I mean by sampling timing: https://i.imgur.com/2LIPJhO.png [23:10:46] that's simulating a fixed shaft angle of 88 degrees with a phase difference of 90 degrees [23:11:36] the CDU settles on a single angle, 16.9025, not because the coarse error has been nulled, but because it is so out of phase that the coarse ternary level is low for every interrogate pulse [23:11:53] so it just nulls the fine system instead of responding to any coarse system error [23:14:36] at least that's what that model does.... it's very possible that I have some bugs in it [23:34:24] I'll look into this carefully tomorrow. It could be possible that my simulation is overly simplified, and a .more subtle one could exhibit totally different behaviour. [23:34:56] But I need some sleep now, see you all! [23:42:35] https://1drv.ms/u/s!ApTRgF_OsQUFgVkmnTj4apmO00tB?e=uydqem [23:42:43] That is my current status.Good night to all. [00:10:03] very nice [14:24:50] .ask ggalfi Can you put your changes in a draft pull request (check the drop down) to orbiternassp/Orbiter2016? Then we can do a review pass over it. [14:52:34] indy91: I have started to draft up some contributing guidelines. Feel free to add things that need to be covered. https://github.com/orbiternassp/NASSP/blob/contrib-guidelines/CONTRIBUTING.md [15:25:29] hey [15:53:09] good afternoon [16:00:27] hey Niklas [16:10:43] looks like ggalfi uploaded his stuff to git [16:14:08] yeah, I had a quick look earlier [16:15:05] I'm still not really sure what to do with it. Either merging it as a whole or in parts. [16:15:38] some parts of it are also geared towards Apollo 11 behaving correctly [16:15:59] instead of being applicable to all missions [16:22:05] right [16:22:42] would it handicap the other missions? [16:24:26] probably not [16:24:40] but I haven only scratched the surface of his changes so far [16:24:43] have* [16:25:08] some of the Apollo 11 specific stuff he uses could become parameters in the mission files [16:26:15] morning! [16:26:34] right makes sense [16:26:37] hey Mike [16:26:45] hey [16:26:46] https://www.youtube.com/watch?v=s3lAmVjtgWM [16:27:44] ah, nice! [16:29:23] spoilers, Luminary 69 has difficulties getting from P64 to P65 [16:29:34] which I find confusing. Don't think it's a padload issue [16:30:04] it got there eventually [16:30:10] hmmm, interesting [16:30:19] so you think it's a 69->99 change? [16:30:53] could have to do with the general update from 69->99 of the guidance equations [16:31:01] have to look at the remaining time in P64 when doing a landing [16:31:18] which is different from the time left in LPD [16:31:41] nice video [16:31:43] could just be how it behaved [16:32:01] thanks1 [16:32:02] ! [16:32:23] the video is half interesting facts about Luminary 69 and half me making fun of my flying and systems knowledge :D [16:32:48] hahaha [16:33:27] I got confused why it showed 10% commanded thrust even after abort staging [16:33:44] but that's normal, that's an internal bias applied in the thrust gauge [16:33:52] in LGC mode that is [16:33:58] auto throttle I mean [16:34:12] in manual throttle that bias comes from the TTCA [16:34:14] confusing... [16:34:38] normally you pull the circuit breaker for that display before a normal lunar ascent [16:36:17] anyway, it's quite fun to watch the LM fight with itself until settling in mid to late P65 [16:36:40] the P65 guidance is quite different between luminary 69 and 99 as well [16:42:08] although I don't know much about the Luminary 69 P65 [16:42:23] I think it might actually try and land at the exact desired spot [16:42:34] instead of nulling horizontal velocity [16:44:48] watching the video now -- I hadn't seen the new tapemeter scrolling, that looks great :D [16:46:55] the video also has the slow DPS ignition that hasn't even made it into a commit yet [16:47:05] still fast enough for Apollo 5 [16:48:14] I just wish the tapemeter scrolling was based on any actual number [16:48:18] but I couldn't find anything [16:50:36] and I did think more about that Sundance constant that looks somewhat like the feet to meters converion. I feel I have seen that value before with the 3.048 instead of 0.3048, in some other context, but I'm not sure where [16:50:47] if you find any reference to it being used then I'm sure we can figure it out [16:54:34] yeah [16:54:44] no luck there yet, and I wouldn't hold out hope, haha [16:54:55] the constants tend to be next to the code that uses them [16:55:07] I finished bank 34 last night [16:55:16] P32 code is almost completely the same as Luminary [16:55:47] as expected [16:55:50] and I know the differences [16:55:53] however this note from a Luminary memo was not joking [16:56:06] "21) P31 was completely rewritten." [16:56:19] I think there might be 0 lines in common, which is impressive [16:56:57] and then P31 got deleted anyway not that long after [16:57:52] poor P31 [16:58:03] so the rest of the P30 stuff should be in bank 35, which I'll do next [16:58:51] Artemis has a new P31, but it has nothing to do with lambert aimpoint [17:01:42] sadly there's not much in common with the Colossus P31 either [17:02:28] it's actually the first time in the sundance disassembly that I've had a reference to another module, without being sure what it is trying to reference [17:03:03] it's loading a constant from bank 26, but there appears to have been a shift there in rev 302 [17:03:12] so whatever it's grabbing is almost certainly not what it wants [17:03:22] even on the RTCC side there was so much work in supporting P31 burns (especially for LOI) that was just never needed... [17:03:25] and I'm not 100% sure which thing it was trying to grab [17:03:44] hmm, that sounds annoying [17:04:14] it's setting it up for a call to INITVEL [17:04:39] single-precision loads this constant, and puts it at PD+0 [17:05:01] which according to the INITVEL comments is "number of iterations of lambert/integrvs" [17:06:13] well that constant it is trying to access is likely 2 [17:06:24] there are no 2s in the area :D [17:06:46] the rewritten P31 also calls INITVEL and has this comment [17:06:54] E4 AND NUMIT = 0 [17:07:01] is NUMIT number of iterations...? [17:07:10] because there is a nearby 0 [17:07:31] hmm, could it be GSOP end of page 223 [17:07:57] that iteration number? [17:08:09] maybe you could supply that number in earlier Sundance revisions [17:09:05] hmm, what do you mean? [17:09:13] average G on or not [17:09:20] but as far as I can see the GSOP only has the N1 as an input [17:09:26] which will be either 0 to 2 :P [17:09:43] input to INITVEL [17:10:21] yeah, I'm inclined to believe it's 0 here [17:10:32] all I am saying is, there is more than one number for iterations [17:10:41] although it looks like only one of them is supplied to INITVEL [17:10:45] rest is internal [17:10:53] if it's not that N1, then it has to be different to the GSOP [17:10:55] yeah, this is the one that is supplied [17:11:29] then it's page 137 at the top [17:12:25] but why would you go through the effort of getting a constant from another bank if that constant is just a 0... [17:12:36] yeah I'm not sure [17:13:11] https://github.com/thewonderidiot/sundance/blob/master/b4_302.disagc#L4915 [17:13:19] that's the address it's using [17:13:29] clearly not an iteration counter, but presumably what it's using can't be far [17:15:48] 1BITDP [17:16:29] yeah I think it has to be that [17:16:46] except it's only a single-precision load so it's just grabing the first OCT 0 [17:16:52] I think Luminary uses P30ZERO for the same purpose? [17:17:02] yep [17:17:27] P30ZERO does exist in the same place in Sundance and is used for other P3* things [17:21:08] so among all the other things Sundance now has become the software of mystery constants and mysterious use of constants [17:21:30] it's possible that P31 was just badly written, and that's why it was completely rewritten :P [17:21:52] heh, yeah [17:22:03] I'm going to point it at 1BITDP so it gets a zero probably [17:22:12] yeah, badly written crossed my mind as well :D [17:22:24] can't go wrong with zero offsets [17:22:25] that seems like it makes the most sense since the rewritten P31 uses P30ZERO for the same parameter [17:22:31] I wonder what Colossus237 does [17:22:34] I did a P31 TLI once [17:22:38] didn't go so good [17:22:51] hahaha [17:22:53] even got some 1210 alarms or so [17:23:01] oh man [17:23:25] hmm [17:23:45] probably not 10 [17:27:12] Colossus also uses N1 = 0 [17:27:41] but it's bad enough that it has to call INITVEL regularly if not everything is set up correctly [17:52:02] indy91, the VC view gets shifted for some reason when deploying the landing gear in the LM [17:52:33] ah, I think I know what that could be [17:52:59] CG shift related [17:54:00] if I go to outside and back to inside view then it fixes it [17:55:06] ah [17:55:27] you did the gear deployment in VC [17:55:38] yeah [17:55:56] does it look like the CG gets shifted when deploying the gear? [17:56:01] it shouldn't do that [17:57:45] if that's not happening then we probably should just call SetView() in SetLmVesselHoverStage [17:58:52] yeah [17:59:56] the only camera related function there is SetCameraOffset(_V(-0.61, 1.625, 1.39) - currentCoG); // Has to be the same as LPD view [18:00:18] I think that only affects the 2D panel? [18:00:32] oh no [18:00:33] of course not [18:01:22] yeah that shouldn't be called anymore [18:01:38] any line like that should just be replaced with SetView() [18:02:08] might not need any call of that there really [18:07:53] right [18:50:48] indy91, the P30s are referencing flag 6 bit 9 a lot in Sundance [18:51:01] in places where there is no corresponding flag reference in Luminary [18:51:13] that bit is 2PHASFLG in Luminary but I'm starting to doubt it's that in Sundance [18:51:21] LM-3 systems handbook doesn't have a flag defined there [18:52:16] yeah [18:52:30] how dare they reference that flag if it's blank in the Systems Handbook [18:53:33] haha [18:54:13] yeah 2phasflg definitely didn't exist yet [18:54:32] 2PHASFLG was short lived anyway [18:54:44] kind of relevant to my video [18:55:03] used for late P64 in Luminary 69 [18:55:18] ... [18:55:20] or not [18:55:51] haha [18:55:52] well somewhat related to that [18:56:33] what could it be in Sundance... [18:57:34] can you point me to an example? [18:58:47] https://github.com/thewonderidiot/sundance/blob/master/b5_292.disagc#L4620 [18:58:54] that's the only place I have committed so far [18:59:04] with lots of unknowns so it's not too helpful :D [18:59:16] is that in P32? [18:59:18] but earlier, just before SCNDSOL, Luminary jumps directly to P32/P72C [18:59:19] yes [18:59:49] in Sundance it instead jumps down to this little chunk, and only jumps to P32/P72C if the flag is set [18:59:53] otherwise it goes to something in bank 32 [19:00:35] ALMXIT also checks it [19:00:42] and it gets set at the beginning of P32/P72B [19:01:32] I need to learn to read AGC code better... [19:02:51] where are references to it. In P32 only? [19:02:54] or P30 and P31 [19:03:05] hmm [19:03:42] and I need to learn which chunks of code correspond to which programs better :D [19:03:48] I think mostly in P32 [19:07:25] yeah [19:07:30] seems like just in P32 so far [19:11:03] oh shit, wait a minute [19:11:14] 19) P10 related coding was deleted from P32 and P72. [19:11:21] I wonder if this flagbit has something to do with that :P [19:11:33] yeah [19:11:42] maybe stored event times from P10? [19:11:51] CSI time for example [19:11:57] that would be P10 only, not P11 [19:12:04] and P32 is CSI [19:12:10] or [19:12:14] initial guess for DV [19:12:17] yeah the address this is jumping to in bank 32 is right in the middle of the P10/P11 code [19:12:21] that has to be it [19:13:08] and that would probably why that flagbit doesn't appear in the systems handbook [19:13:09] if it's CSI time, maybe the flag is set if the astronaut has enter a CSI time [19:13:11] if it's specifically for p10 [19:13:12] or TPI [19:13:18] yeah [19:13:23] we'll see what happens with this flag in P10 :D [19:14:05] damn, that part of the really old LGC GSOP is not readable [19:14:21] which page is it on? [19:14:53] 274 [19:15:31] not that that would be anywhere close to the Sundance P32 [19:15:54] oof [19:16:55] in general the equations there are not really mature enough for software yet [19:17:04] in those early GSOPs [19:17:21] speaking from lots of experience implementing them in code [19:17:25] oh boy [19:17:32] that doesn't give me a lot of hope for the P10/P11 section lol [19:17:53] P10/P11 is among the best there haha [19:17:59] oh good [19:18:38] hmm [19:18:41] DOI TIG prediction could be better [19:18:50] I wonder if the Luminary 1D flowcharts have any bad outdated things that reference this flag [19:19:31] oh like the AOH Volume II for Artemis [19:19:38] Artemis with the super capable P20 [19:19:58] but the AOH still has procedures for orb rate and PTC using the old method [19:20:05] heh [19:20:06] manipulating DAP erasables [19:21:23] "and it gets set at the beginning of P32/P72B" any place where it gets reset? [19:21:29] net yet [19:21:32] *not yet [19:21:36] hmm [19:21:40] maybe P10 resets it? [19:21:45] yes, that's exactly what I'm thinking [19:22:05] and they call common code, and this stuff uses the flag to figure out if it should go back to P32 or P10 [19:22:16] oooh [19:22:23] so this would be P10 using P32 code [19:22:26] not the other way around [19:22:30] I think so [19:22:42] that makes sense [19:22:47] :D [19:23:45] well that's exciting [19:24:02] and means my job in P10 is slightly easier if it's sharing some code with P32 [19:24:35] I think we might even have that in the old GSOP [19:24:40] page 266 [19:24:47] Compute CDH maneuver using... [19:25:26] oh nice [19:25:39] and refers to the P32-34 flow chart [19:25:50] execllent [19:29:57] yeah I don't think the actualy CSI maneuver calculation would be useful in P10 [19:30:10] but the CDH maneuver calculation in P32 is [19:30:18] which is what that early GSOP does [19:31:40] yeah, the P10 CSI maneuver aims for a DH, not iterating on TPI time [19:32:07] so I'm quite sure that that detour to P32 equations is about the same as in the early GSOP [19:33:36] great [19:33:43] stuff like this is why I'm saving P10/P11 to the very end :D [19:33:59] now we know more about what we're going to find there, haha [19:34:18] yeah [19:36:02] into P33/P73 now, now big differences so far [19:36:08] different nouns but that's not unexpected [19:37:41] oh really [19:38:05] oh yeah lots of these nouns are different [19:38:08] for the P30s [19:38:47] yeah, I'm seeing it [19:39:03] N13 is N31 in Sundance [19:39:20] same with 50 and 75 [19:39:46] 75 Luminary, 50 Sundance that is [19:43:31] yep [20:40:30] night! [13:48:30] hey n7275 [13:48:44] have you tried ggalfi's landing scenario yet? [14:14:53] I haven't had a chance too, unfortunately. I checked it out last night and went to bed. [14:16:08] I'm at work when most of you guys are online (I live east coast us) [14:17:37] yeah, time zones can be a bit of an issue, haha [14:17:51] well the scenario did something weird for me, I just wondered if it was just me [14:18:38] the scenario starts at PDI-1 minute, which is also what the DSKY has saved in the scenario. But once I start the scenario it is at a few minutes past PDI [14:27:50] I'll run through it tonight [14:29:24] sure. I have a bigger Apollo 5 update to finish, but after that I can start properly looking at these AGC updates to see if we can merge them :) [14:47:35] maybe he just included the wrong scenario, or overwrote it or something. [14:48:09] it's also thrusting straight down after ignition... [14:48:12] yeah, maybe, haha [14:50:15] I tried reading through the cdu code, but that's definitely something I need to read through in the daylight hours with a proper amount of coffee... [14:51:22] same :D [14:53:58] unrelated question: is the wiki forever stuck in sourceforge limbo? [14:59:19] hmm [14:59:29] yeah, there are a bunch of issues with the wiki [14:59:36] you can't create new accounts anymore [14:59:56] among other things. I think the only real solution is to create a new one and copy over the old articles [15:05:20] that's probably the best solution [15:25:46] hey [15:33:50] hey Alex [15:37:33] hi Alex [15:52:11] the AFJ has uploaded the LM-7 AOH Volume 1 [15:52:20] 600MB file :D [15:52:33] I'll download, maybe it has some unique things in it [16:07:15] morning! [16:09:07] Hi all, [16:10:33] I can see that pull request question. Will comply. [16:11:30] However I'll do some changes on my code as I've left accidentally some of my joystick code in it. [16:12:49] So if you have any issues with manual throttle, it is due that code. [16:16:33] But first I transfer these snippets into my vkbstick branch, and after that I will do that pull request. [16:50:03] hey ggalfi [16:50:34] I tried your pre PDI scenario, didn't go so good [16:51:05] for some reason the DSKY showed that it was already about 2 minutes after PDI [16:51:21] although in the scenario it definitely had PDI - 1 minute saved [16:51:28] and then it thrust towards the Moon... [17:13:40] using our old scenario and it works great [17:15:13] hey ggalfi [17:16:28] gettings 1201 and 1202 alarms [17:17:18] getting* [17:17:25] nice logic for that in the RR :D [17:17:26] if (lem->ApolloNo <= 11) enable_phase_bug = true; [17:17:27] else enable_phase_bug = false; [17:20:00] so I guess the update works quite well, except for the scenario that ggalfi provided [17:20:24] although I wouldn't be able to tell if all the yaAGC changes are good... [17:22:58] yeah I'll have to take a closer look at that [17:23:56] that would be great [17:26:00] any new Sundance surprises? :D [17:26:16] there was a chunk of code at the beginning of bank 11 that I couldn't identify [17:27:06] turns out, it's a section of S34/S35.2 that is just extracted and placed into another bank [17:27:22] for Luminary they just put it directly in line with the S34/S35.2 code [17:27:24] huh, weird [17:27:34] I'm wondering if maybe P10/P11 are going to also call it or something [17:27:55] uhh, what else [17:28:17] it does call the Lambert routine at least [17:28:29] both P10 and p11 [17:28:54] nothing else major [17:29:02] there's only four banks left -- 30, 31, 32, and 33 [17:29:15] I think I've avoided the descent/ascent code as long as I possibly can [17:29:33] so tonight I will just start going through them in order [17:29:38] bank 30 begins with the entry point to P12 [17:30:08] well, maybe not in order [17:30:17] 31 has P10/P11 at the beginning [17:30:24] avoid descent, ascent and launch time prediction :D [17:30:26] although I can skip over them to the P63 entry point [17:30:27] avoided* [17:30:31] hehe yeah [17:30:56] oh there is a new LM AOH Volume I [17:31:00] LM-7, Apollo 13 [17:31:04] oooohh nice [17:31:06] link? [17:31:10] 600MB download :D [17:31:30] https://history.nasa.gov/afj/ap13fj/a13-documents.html [17:31:52] oh dear [17:31:57] I downloaded it, I'll look through it if there is anything new or interesting [17:31:58] that could probably stand to be compressed a bit lol [17:32:09] and I complained about your file sizes haha [17:32:28] definitely pretty nice quality [17:32:59] my file sizes were like this with no compression haha [17:33:52] maybe it tells us something about FP7 we didn't know before [17:34:13] oh that would be excellent [17:34:17] has good lists of addresses, if we didn't have that already [17:35:39] hmmm, I don't remember, we might not have [17:39:25] no surprises [17:39:39] just a nice, high quality, pre J-mission AOH Volume 1 for the LM [17:39:45] and looks rather complete [17:40:19] cool [17:40:32] I'll compress it a bit and send it off to Ron [17:42:50] well as ggalfi has left, I might as well checkout my Apollo5 branch again and try to get that done [17:43:36] I was worried docked stages would be bad for accelerometers [17:43:59] but somehow the Apollo 5 launch has the most accurate LVDC state vector of all missions??? [17:44:05] I won't complain [17:44:16] hehehehe [17:44:22] maybe it's the CG shift that is done at staging [17:44:28] state vector being suddenly changed [17:44:52] in the old version [17:44:59] with all stages as one vessel [17:45:18] now the S-IVB/IU has one CG that stays the same [17:45:25] could be that [17:46:52] ah yeah that could definitely have something to do with it [17:47:05] probably not taking into account in the LV IMU [17:47:19] and it's probably causing a bit of weirdness in the gravity calculations of the IMU [17:48:09] today I am making the engine start/stop buttons in the LM VC [17:48:42] ah nice. At least the panel they are on has a fairly simple shape :D [17:48:48] the stop button takes a bit of researching to get right, it doesnt look the same as what we have in the 2S panel [17:48:54] 2D* [17:49:53] yeah, it's quite weird [17:49:54] the stop button is on the side and it seems the whole latching mechanism covers the stop button itself [17:50:07] and the descent rate switch is just behind it, right? [17:50:22] I think I understand how to animate it though [17:50:36] or under it I think [18:55:10] random Sunburst program alarm, nice [18:56:10] or not random... [18:56:24] but I've never had on in this place, at S-IB/S-IVB staging [18:56:27] Sunburst program alarms are my favorite :D [18:56:40] V15 N50, 205 [18:57:00] all I changed was a few valves being open at launch [18:57:33] maybr RCS related? I think Sunburst opens the RCS explosive valves through the programer [18:58:15] THE SERVICER ROUTINE CHECKS FOR RUNAWAY PIPS (DELV GREATER THAN 3200 PULSES/SEC FOR 2 SEC) AND SENDS ALARM CODE 205 IF BAD PIP IS FOUND. [18:58:41] I did not accidentally stay in ggalfi's branch :D [19:00:04] don't think I ever had that alarm before, very weird [19:00:59] I know that the IMU needs to have a certain orientation to avoid the PIPAs being beyond the limit [19:01:11] huh [19:01:25] so, extreme acceleration detected [19:01:29] I guess [19:01:43] but I didn't change anything, I switched branches back and forth, but that's it [19:01:47] I'll try a rebuild [19:03:36] one pulse for the LM is 1 cm/s [19:03:44] so 3200 pulses is 32 m/s [19:04:20] over two seconds [19:04:42] 16 m/s^2 is the limit? Quite low [19:05:23] not sure how that can work even if you have the IMU oriented is such a way that that gets split up over all PIPAs [19:05:35] that's the maximum that can be detected by the pipas though [19:06:24] pretty sure Apollo 5 got up to 4G [19:11:03] yeah, it happens late in the launch [19:11:14] yaw angle is near 0, that can't be good [19:12:07] so what changed... [19:20:00] hmm, it wasn't doing the gyro compassing properly anymore [19:20:18] I changed TIME1 and TIME2 in the scenario [19:20:27] but I thought I had flown some tests after I did that [19:22:23] if I stop P02 and restart it I get no program alarm [19:27:22] maybe I messed up the timers by manually changing the clock time [19:28:16] TIME3 etc [19:31:13] or at least the timer related to the gyro compassing [19:31:15] damn [19:31:24] will be hard to fix this scenario if that is the case [20:29:27] night! [12:51:01] Hi all! [12:53:09] Hey Indy, I've seen in the logs that you had problems with the scenario I provided and things went correctly with "normal" scenarios. Is that correct? [12:56:53] I mean regarding the agcio branch [13:03:25] hey [13:03:27] that is correct [13:05:18] the scenario had a DSKY state saved that show PDI minus 1 minute [13:05:24] which is correct I guess [13:05:36] but once I started the scenario it suddenly showed PDI plus 2 minutes or so [13:05:55] and after ignition the LM was thrusting directly at the Moon [13:08:37] I guess the guidance got confused because ignition was late or os [13:08:40] or so* [13:11:21] Could you please do a test for me? If you test that scenario immediately after startup of Orbiter, that would be meaningful. I have an issue with my Orbiter setup which appears when I exit from a scenario (Ctrl-Q) and select another one without restarting Orbiter, sometimes I can see odd behaviour. I guess due to soem memory leak caused by some bad [13:11:21] cleanup processes. As it happens occasionally, I wasn't sure that it caused by my D3D9Client hack or my NASSP developments. But certainly could be my mistake. [13:13:23] sounds familiar. Probably NASSP bugs [13:13:32] but I'm quite sure it's not that [13:13:45] I did test the scenario first thing after starting Orbiter [13:15:04] Also please be aware, that yesterday I removed some codes from agcio which was related to my joystick hack. The previous version could have cause controlability problems if you are using a different type of joystick than my lovely VKB flight stick. [13:15:25] ok. didn't even have a joystick connected [13:15:36] However it wouldn't explain any LGC mess up. [13:15:54] yeah, it has to be something with the saved LGC state [13:17:46] really don't know what else could cause the time to PDI to have such a jump [13:18:14] Certainly my scenario works flawlessly on my machine with latest agcio version. What could be useful here: if you startup my scenario and save it immediatelly, maybe I can figure out what is going on. [13:19:14] yeah I'll definitely test it with your latest agcio branch [13:19:45] I'm in the middle of an Apollo 5 APS burn, but after that I'll switch branches and test it again :D [13:21:20] I have changed fairly deeply the timers of the AGC. I introduced the scaler thing, and changed the full control of the timer registers according to real hw. So something of that could be the culprit but why it happens on your machine and why not happening on mine - it is a mystery. [13:22:13] hello [13:22:32] Hi [13:22:42] haha, I just had messed up the timers in my Apollo 5 prelaunch scenario. Apparently modifying TIME1 and TIME2 in the scenario during gyro compassing wasn't a great idea... [13:22:43] hey n7275 [13:23:51] There is also a Virtual AGC update sitting since forever as a pull request on Github which changes some of the same things as you did [13:23:59] I never got around to implementing and testing it [13:25:35] I'd hate to diverge from the current Virtual AGC more, so if your update gets merged then probably after thewonderidiot has looked through it and made a version that works for both the standalone Virtual AGC and NASSP [13:25:35] I tried ggalfi's updates last night and got some odd behavior, might just be my slow computer though [13:27:11] I didn't get bad performance or so, at least not enough that I could attribute it to the update [13:27:59] attitude control even before the burn was very unstable, to the point where it would use up all the rcs fuel in about 8 min [13:29:24] sounds like timer problems [13:29:28] I'll check if I also get that [13:29:39] it was fine during the powered descent at least [13:31:28] On Apollo 5: I've seen in the logs that you had issues because of some over-G condition. That makes me think to rework my PIPA simulation as it can handle the over-G (it will generate 3200pps constant plus or minus PIPA signal in that case), however the recovery from that state would be slower than the real hw. My calculation is a linear [13:31:28] approximation for a pendulum, which works well when the PIP could maintain the equilibrium, however not so good when it is overloaded. I never thought that an LM could be operated with more than 4g without crushing it :) [13:31:46] oddly the dt was actually less (0.05 sec on average) in this pr branch, than in the orbiter2016 which is more like 0.06 ish [13:32:26] oh that issue was caused by me manipulating the timer in the AGC [13:32:32] caused gyro compassing issues [13:32:38] so the attitude at liftoff was wrong [13:33:06] and that caused it, shortly before S-IB cutoff, to have too many PIPA pulses in one axis [13:33:13] the alignment is specifically chosen to prevent that [13:33:31] so I got it fixed [13:34:50] but yeah, Apollo 5 experience about 42 m/s^2 at S-IB inner engine cutoff [13:35:09] has to endure something similar during any Saturn V flight [13:36:44] ok, switched branches [13:36:52] issue still happens in that Apollo 11 scenario [13:37:06] If I go to P00 and back to P63 I get the same issue, I'm already past PDI TIG [13:37:46] Could you please compare the MET and v16n65? [13:38:36] sure [13:39:03] that is the issue I guess [13:39:15] MET 102:32:05 [13:39:33] N65: 102:34:49 [13:39:59] It is the same on my machine. [13:41:17] TIME1 and TIME2 look correct in the scenario though [13:41:27] so the jump has to happen just when the scenario is started [13:41:50] EMEM0024 4314 [13:41:51] EMEM0025 35625 [13:41:57] 102:32:00.21 [13:42:08] It could happen if you load my scenario with the old agc engine [13:42:37] in the draft PR I saw that you also changed some folders [13:44:50] or at least something in the project files [13:45:02] yaAGC [13:45:06] to [13:45:07] Source Files\yaAGC [13:45:09] for example [13:45:20] Which folders? I haven't intended to do that. Even I tried to avoid to incorporate new source files to avoid messing with the project file itself. [13:46:36] hmm, only that one project file though [13:46:40] not the LM [13:46:49] and I definitely have your modified yaAGC files [13:48:50] Oh yes, there was a point when I considered to incorporate my own AGC implementation (I've created one from scratch based on schematics), but omitted that to go on gradually. And tried to use files which are already there (like cdu.cpp) Maybe that caused these oddities in those filters [13:48:51] n7275, do you get the same? [13:49:01] when you try ggalfi's scenario [13:52:15] One important thing: are you using AGC in single threaded mode? Because multithreading was the aspect I totally disregarded during development, and tested everything in single threaded mode. [13:52:53] ooooh [13:52:56] that could be it [13:52:59] didn't change any settings [13:53:39] unfortunately not [13:53:43] still the same [13:55:59] I don't have any DAP issues [13:57:04] yeah I was in multithreaded [13:57:49] Both indy and n7275: could you send me a saved game file right after loading my PDI scenario? Based on that I try to figure out what is going on here. [13:58:01] sure thing [13:58:30] I can...in about 7 hours when I'm home.. [13:58:39] my DAP also works fine in multithreaded [13:58:42] well [13:58:54] at 1x time acceleration it doesn't do multi threading anyway I think [13:59:16] so for anything I have tried so far it wouldn't make a difference [14:01:38] Thanks, it was just an idea. The correct behaviour highly depends on being AGC and IMU in sync. If not, you may loose counter signals which could result e.g. in divergence between the actual gimbal angle and CDU regs. [14:02:41] well right now I rather lost 2 minutes in time than CDU counts :D [14:04:04] Yeah, it is much larger than could be explained by that. [14:05:37] I got the file, thanks as well. Now I'm looking into it. [14:06:21] interesting [14:06:32] I get another time jump when I open that quicksave [14:07:04] about the same length again it seems [14:07:22] got to P00, closed and open again [14:07:25] not another time jump [14:08:21] It is little bit more than 3 minutes, isn't it? [14:08:55] a little less I think [14:09:03] MET 102:32:05 [14:09:06] N65: 102:34:49 [14:09:18] that's what I wrote earlier, I think that was quite precise [14:11:41] I don't always get a time jump when I open a scenario [14:12:01] or rather open, close, open, close, open your scenario [14:14:17] I've seen a similar bug druing the development. It was due to that I wrongly implemented one of the TIMER register increase . I corrected that (up to my knowledge) and I didn't have any problem like that since, but at least it looks familiar. [14:16:47] hmm [14:17:06] then are you sure the correct yaAGC version is on your Github? [14:20:23] I've checked out the agcio branch yesterday, cleaned and build the whole project. Maybe I can try to manually cleanup all NASSP related stuff and reclone-rebuild everything. [14:23:28] found a bug [14:23:36] else if (!strnicmp(line, "SCALERCHANGED", 6)) { [14:23:37] int tmp; [14:23:37] sscanf(line + 6, "%d", &tmp); [14:23:38] vagc.ScalerChanged = tmp; [14:23:38] } [14:23:44] I don't think that will load correctly [14:24:31] the 6 is wrong [14:24:37] has to be the same number as the length of the string [14:24:50] unfortunately it doesn't fix the issue... [14:27:02] Wow, great find. I've overlooked it somehow. [14:27:42] I do have the feeling something goes wrong on the first timestep [14:27:47] probably does too many AGC cycle [14:27:50] I'll try to debug that [14:32:30] hmm, nothing obvious [14:43:22] How intertwined are all these changes anyway? Merging will be a lot easier if changes are implemented bit by bit. [14:44:39] quite intertwined [14:44:59] Looking at the PR there are 3 commits that add over 18k lines. That makes it very difficult to tell what does what and to go into why a certain change was made. [14:45:02] the changes to the DPS are probably fairly easy to merge separately [14:45:55] everything else only works together, I think [14:46:50] What about the changes to agc_engine? I don't think we want to be diverging again since we've been working years on getting in line with upstream again. [14:47:32] If there are things that need to be changed to yaAGC a PR should be made in the virtualagc repo, not here. When they are merged there they can be included in NASSP. [14:49:35] These changes could definitely be done as a single PR if they rely on each other. But they shouldn't be in just 3 commits as they are now. [14:50:14] I think the only way forward for that is someone with the right knowledge (so only Mike) creates an update for both NASSP and Virtual AGC, using the best bits of Mike's still unmerged counter update PR and ggalfi's changes [14:55:49] Agreed. I'm not trying to sound harsh in anyway, I'm all for people who want to contribute, but looking at the PR and seeing absolutely huge parts of code being commented out with the only way to find out why that code no longer works is by digesting 18k lines of code is not the way a PR should be made. [14:58:29] I agree. To be fair, the goal was not to create a PR for NASSP but to get Apollo 11 as realistic as possible, mostly for personal amusement [15:00:07] no update like this will be easy to figure out. That's why I never got that far into implementing Mike's PR for the Virtual AGC [15:02:44] Okay, I thought the intent was to get everything merged. I can definitely see this living as a fork for people to have a very accurate Apollo 11 experience and would love to see those come to NASSP (more sim = more fun). Achieving that will take a long long time. [15:03:10] Just looking at the time it's taken to just get the AGC merged (circumstances aside). [15:03:28] and manually merging Virtual AGC updates... [15:03:33] not a lot of fun :D [15:04:18] Having the virtualagc repo as git submodule is still a silent hope for me. No longer worry about diverging. [15:05:49] that was my idea when I started implementing Mike's counter update. I used the identical agc_engine files as the Virtual AGC and started fixing things from there [15:06:04] Are those high res textures up? I can see those being fairly trivial to merge. [15:06:13] but it was one project too many, counter update and fixing all the remaining differences [15:06:44] not sure [15:08:17] Best approach is to get synced with the current master first and then start worrying about counters. One babystep at a time. [15:10:08] you mean merge the Orbiter2016 branch changes into the agcio branch? [15:12:57] No, I was referring to the AGC differences [15:14:31] oh [15:14:51] hmm, can't really remember what the remaining differences are [15:14:55] something with downrupt [15:14:59] Sidenote, I just found out all GitHub repos, including ours, were archived to the Arctic World Archive in Svalbard in Febrauary. https://archiveprogram.github.com/faq/ [15:17:53] that's a lot of repos [15:18:33] All stored on film: https://youtu.be/fzI9FNjXQ0o [15:20:49] fun [15:21:30] Great, nobody will remember anything about me other than I can't code for shit. [15:21:40] Haha [15:24:39] you did more than a few commits 4 years ago? :D [15:25:15] hey [15:27:23] Hey Alex [15:29:32] My other work is on github too [15:35:45] You LambdaDelta thing looks pretty neat [15:35:57] s/You/Your [15:37:25] Thanks [15:37:52] In another channel, I just announced to a few early birds the near-availability of something related to that so they could check it out [15:38:03] "I expect it to die horribly and/or be overrun by spambots the moment the internet at large finds it." [15:38:11] "The closer I get to releasing it the more I feel I am making a very grave mistake and I should run away while I still can." [15:38:28] Just as I was typing those words, two things happened more or less simultaneously: [15:38:34] 1: The entire datacenter just got blown off the internet [15:38:41] 2: A large chunk of tree, previously damaged by lightning, just fell on my roof [15:39:00] I think I should probably take a break for awhile... [15:55:28] haha, yeah sounds like a sign! [15:55:31] hey Alex [15:56:41] Yeah; People started bitching right off the bat. [15:56:48] Deleted project, shut down site, fuck this. [15:56:52] I've had enough. [15:57:02] This was a sign if there ever was one. [15:57:12] just don't do that with NASSP [15:57:32] No; You guys contribute and don't quabble over politics. [15:57:43] If anything you guys should be telling me to go pound sand [15:57:56] we have the advantage of living in the past :D [15:58:11] https://www.dropbox.com/s/yw11940eq3vj8hn/Screenshot%202020-06-09%2009.57.24.png?dl=0 [15:58:44] very nice [15:59:28] thanks [15:59:50] still need to add the start button [15:59:50] back to the Apollo5 branch... [16:00:06] got past APS-2 burn without issues, so I'm very close to merging it [16:00:14] nice [16:00:33] proving docked Saturn stages work [16:00:40] fixed the timer issue I guess? [16:00:53] had to start from the T-1 hour scenario again [16:01:15] manipulating the clock time while in anything but P00 is bad I guess :D [16:02:00] must have messed the timer associated with the gyro compassing task [16:05:32] ah I see [16:06:19] back to P00 and to P02 fixes it, but then I don't have a T-60 seconds scenario anymore [16:06:33] more like T-10 seconds once it's again where it was before [16:11:06] only thing left to check is if the separated S-IVB does all the right things for all missions that are not Apollo 5 [16:15:46] Hey, I'm back. Just have seen the discussion on how to proceed with my development. What I want to make it clear, that my main goal was increase the overall accuracy of the simulation. LM5 landing was just a use-case where this increased accuracy could be quite well demonstrated as there the guidance system was operated in an "outside of the [16:15:46] envelope" mode. However there are other improvements which are not so obvious but still gives improved accuracy: the new PIPA allows you to do correct trimming after burns (and even the auto burns are executed with some increased accuracy), the realistic load of the gimbal CDUs seem to me increased the stability of the DAP. So I've done the whole [16:15:47] development with the intention to improve some of the capabilities of NASSP without ruining any of them (only exception is the multithread option, which - if really hurts - I think we can easily cure). [16:17:10] The second important point here is that even my PR contains 18k+ lines, 15k of them is a test scenario. [16:20:36] and of those 15k way too many are probably the Checklist MFD :D [16:21:03] well we will see. I think your update is great and I hope we find a good way to integrate it [16:24:31] To make the life easier for you, I can sew in my changes in the current version, with a sequence of commits. My development is not carved in stone, so I can try to split my code in a meaningful manner. It will take some time, though I'm happy to do that if you think it will helps proceeding further. [16:27:44] I don't think that is necessary [16:50:59] morning! [16:51:31] hey Mike [16:51:58] Hi [16:56:17] what's up? [16:56:19] Hey Mike [16:57:01] I've got an exam for my amateur radio license next week which I'm currently studying for. [16:58:52] oh nice! [16:58:54] good luck :D [16:59:53] I'll need it. :P [17:00:03] I'm not a natural at analog electronics. [17:00:51] I get college credit for it though, which is nice. [17:01:27] oh that's super nice [17:02:25] I probably spend half the amount of time those credits are worth just in emails to get them in the first place haha [17:02:41] hehehe [17:02:57] Looking at the CDU schematics for a long time helps a lot. During the past year are relearned such words as "emitter follower" and "operational amplifier" which I totally forgot for 20 years. [17:03:24] hahaha yeah for sure. the CDU is a strange analog contraption :D [17:04:13] maybe someone can explain to me how that secant amplifier in the GDC work then :D [17:04:38] we do know that guy with the prototype GDC... [17:06:07] that amplifier is "calculating" 1/cos(yaw) [17:06:19] and that goes to infinity at yaw = 90° [17:06:25] and that is the GDC version of gimbal lock [17:09:07] that's fun [17:09:21] so I guess it would just saturate its output [17:10:01] yep [17:10:11] that's roughly how I implemented it [17:10:17] a maximum output [17:10:51] so if you maneuver beyond 80° yaw the GDC attitude accuracy degrades [17:11:01] yeah that sounds about right [17:11:30] so I started working on P12 last night [17:11:39] unsurprisingly it is extremely different :D [17:11:44] haha [17:11:59] oh I was wondering, P12 and P63 etc. can't be accessed with V37E, right? [17:12:05] but not in the P30 kind of way -- there are still a lot of chunks that are shared, or equations that are the same but implemented slightly differently [17:12:36] hmm, interesting [17:12:37] they sure can :D [17:12:44] oh [17:13:09] my follow up question would have been if there was another way to start them [17:13:40] P22, P31, P67, P68, and P76 are the only ones that Luminary has that Sundance can't start with V37E [17:13:50] er sorry, P31 can be started [17:14:17] and by P67 I meant P57 [17:14:18] ah ok [17:14:19] haha [17:14:20] ugh typing [17:14:27] P22, P57, P68, P76 [17:14:32] those can't be started with V37E [17:14:56] I see, not too bad [17:15:05] and all I know about P12 is that it wasn't implemented very efficiently and most changes are probably related to that [17:15:42] but yes, for the ones that don't have V37 entries, we can start them manually with V30 [17:15:56] not that you should. But you can :D [17:16:04] hehehe [17:16:53] wait, P76? Did I already forget about that? [17:17:13] I thought it had that as an extended verb only [17:17:46] oh yeah, Sundance has it as an extended verb [17:17:54] sorry, I was just looking at the V37 tables, haha [17:17:59] haha ok [17:18:54] also, a looot of the numbers are different [17:19:04] even though the scaling looks to be mostly the same [17:19:40] (AT)A, (TBUP)A, (TGO)A, etc. [17:19:47] lots of constants used in P12 [17:21:26] yeah, maybe they are still like in that early GSOP [17:21:54] oh it has numbers for that? iiiiinteresting [17:22:14] 945 for (TBUP)A [17:22:29] or 94500 I guess [17:22:37] okay let me check that [17:22:38] instead of 91902 [17:23:27] (AT)A. Luminary: 3.2883 Early GSOP: 3.2004 [17:24:28] hmm [17:24:30] (TGO)A. Luminary: 37000 Early GSOP: 45000 [17:24:30] not quite [17:24:44] well, those numbers will depend on the LM mass and engine properties [17:24:58] so I can imagine they changed over time with updated knowledge of what will fly [17:27:15] ahh gotcha [17:27:33] yeah (TBUP)A in Sundance looks like it is 982.79 [17:28:03] okay so it's not unexpected that those are all different [17:28:04] good :D [17:28:31] pretty large, but not too much [17:28:45] they are initial guesses [17:28:48] yeah [17:28:49] all of them [17:29:38] excellent [17:29:44] so I should be able to finish P12 tonight then [17:30:25] nice [17:30:32] then the descent programs? [17:30:42] hmm [17:31:37] yeah [17:31:47] bank 31 is next [17:32:01] things that I know are in there: FLATOUT, LUNLAND, P63DISPS [17:32:25] haha, what is FLATOUT? [17:32:55] FLATOUT THROTTLES UP THE DESCENT ENGINE, AND IS CALLED AS A BASIC SUBROUTINE. [17:33:24] I think that being the timed throttle up in P63 [17:33:31] ah [17:33:36] well the name makes sense [17:44:46] if people were impressed that Luminary 69 can land and launch [17:44:54] what would they say if Sundance works :D [17:46:05] maybe you see more of a difference with Sundance [17:46:24] the only differences you could really see with Luminary 69 was late P64 and P65, and a bit P66 [17:46:34] hahaha yeah I'm super curious [17:46:46] I can't wait for you to start abusing the poor program :D [17:55:15] you know what else has fully functional descent and ascent programs? Sunburst [17:55:29] but it might be tricky to get to work in lunar orbit [17:55:53] oh jeez [18:00:24] but it works great now (again) in Earth orbit [18:04:54] Indy, your Apollo 10 video made me feel a bit sorry for Tom Stafford. I always thought that even if the Apollo 10 crew would get the "lightweight" LM5, due to lack of proper software they wouldn't have chance for a successful landing. But your video shows, the software would've done it's job on Snoopy as well. [18:06:22] to be fair, I didn't actually make the ascent stage as heavy as it should be. [18:06:29] forgot to do that before the video [18:06:34] but the result would be much the same [18:06:45] landing is easy, as half the APS propellant is missing [18:07:16] and the software does indeed work, especially well in the idealized NASSP [18:07:28] it didn't account yet for, actually, some of the delays you implemented [18:07:41] like the delay of the signal to the DPS [18:08:19] maybe I should try my landing scenario in your branch [18:08:25] also with the updated mass... [18:12:03] landing would be easy. crashing into Mare Fecundatis would kinda suck though [18:13:23] yeah you don't go that far from the landing with that little APS propellant [18:14:04] I'm only doing some sort of speculation. What I've learned that LM4 was too heavy for a full descent-ascent cycle. The big heads at NASA considered to gear up LM5 for Apollo 10's launch in May, but soon skipped the idea as there were still too many unknowns. Even the handling of 1201/1202 errors were trained for the MCC people in a simulation in [18:14:04] June, so having those during an Apollo 10 PDI would've likely resulted in an abort decision. [18:16:10] yeah, if they didn't knew as much as they did about the alarms... [18:16:45] one thing I want to try, full APS propellant for Snoopy [18:16:51] does it make it into orbit? [18:16:53] but there's only a (small?) chance that those alarms would occur [18:16:55] I'd say yes, but it's close [18:17:04] true [18:17:52] I bet I'll get the ASP quantity alarm [18:17:54] APS* [18:38:00] didn't even get the alarm, no problem [18:38:19] if the masses we use are correct the LM ascent stage was only 150kg overweight on Apollo 10 [18:58:07] Indy, compared your save game with mine (I saved the state approximately at the same time), and and at the moment there is only one significant difference: TIME2 (EMEM0024) is 04314 in my scen and 04315 in your scenario. So it explains the 164 sec difference. But that is odd, because the TIME1 is fairly consistent in the two scenario, so for [18:58:07] somewhat reason an counter increment signal is executed on load when you run the scenario. [18:59:30] Still looking for the reason for that, but I'm suspicious that some sort of memory leak problem we have here. [19:04:31] ah, so the difference is 2^14 centiseconds, very interesting [19:06:49] maybe something isn't getting initialized [19:06:57] sounds like that sort of problem [19:07:22] Yes, that is the direct cause of the LGC feels itself 1+ minutes behind PDI. [19:08:00] And yes, that initialzation and load process I'm looking at very carefully. [20:18:58] hmm, now that we can use docked stages [20:19:14] if we ever want to implement a Block I CSM [20:19:22] it doesn't have to have anything for the Saturn [20:19:28] which makes things easier [20:22:03] oh nice :D [20:22:07] solarium gogogo [20:23:18] I like to start the beginning [20:23:21] at [20:23:29] so S-IB-1 on LC-34 first :D [20:23:39] hehehe [20:26:05] then I make a AS-201 video, send it to Francois, and tell him to hurry up [20:29:40] "have you still not fixed Corona?" [20:29:58] https://www.youtube.com/watch?v=1Isjgc0oX0s [20:30:56] Is PanelSDK something that was build specifically for NASSP or was it forked from somewhere? [20:31:40] There are some interesting similarities to the Dragonfly systems simulation [20:31:51] but I'm not sure it really comes from there [20:32:47] either it served as the inspiration or some of the same people worked on both [20:33:34] It's listed in the source as part of NASSP under GPL2 copyright by Radu Poenaru [20:33:46] Implying it was 'in house' [20:34:59] .ask Suzuran Where did PanelSDK come from? Is it build as part of NASSP or is it forked from somewhere and is there still someone that 'maintains' it? [20:37:01] If it is not originally part of NASSP I have some concerns about that GPL license. Need to be sure it was licensed under GPL (compatible) originally. [20:37:33] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=132.0 [20:37:35] Down the line all copyright headers in all the source files need to be fixed/updated [20:38:19] https://www.orbiter-forum.com/showthread.php?t=12067 [20:38:35] it existed for a year at least before being integrated into NASSP [20:38:55] good detective work [20:40:06] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=99.msg748#msg748 [20:40:17] "Good news, Radu agreed to the GPL! " [20:41:03] SPSDK is freely distributed software in the sense that you are free to download, copy, redistribute [20:41:04] it and use it as part of your Orbiter add-ons, provided that proper credits are accorded for the [20:41:05] SPSDK, and that the add-on created using SPSDK is distributed freely. [20:41:41] Hmm that's nice [20:42:46] There is no actual direct confirmation from him though. [20:42:55] So technically that doesn't hold up. [20:44:33] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=389.msg4291#msg4291 [20:47:29] Seems convincing enough. [20:49:22] Might be worth to do a separate release of PanelSDK so others can use it with our additions and so we don't have some out of tree hacked together version. [20:50:23] it's a bit of a mess to be honest [20:50:54] maybe after Ryan has done his updates [20:54:03] Seems Radu was last active on the forums 4 years ago [20:54:28] the PDF doc that comes with the SPSDK 1.7 on OHM seems to explain a lot of stuff...maybe it will help with figuring out the thermal issues we have in the LM [21:02:46] yeah I have to take a look at that [21:02:50] night! [21:13:21] I actually just spoke to Radu on facebook teo days ago [22:05:20] Hey Mike, can you help me out with some debugging stuff? [22:08:23] ggalfi: I can try! what's up? [22:11:05] So the probelm is that both Indy and n7275 have some issues with running my agcio branch. The problem is that I cannot reproduce any of them. First want to make sure that the process I follow to build my own branch is the same as you are usually building it. [22:11:34] So 1. git checkout agcio [22:11:41] 2. git pull [22:12:05] 3. In VS I clean the solution and build the Release version [22:13:21] Is this what you are doing when you try out an experimental branch? [22:14:05] ah, I am not the best person to ask, since really the only thing I've ever done with NASSP was modify it to talk to the real AGC [22:14:10] but that sounds right to me [22:18:55] Cleaning it and rebuilding should work [22:19:36] And are you building the Release, not the Debug version, aren't you? [22:19:53] Usually Release unless I'm testing something specific. [22:19:59] yeah, I always did release [22:20:05] Debug is really unoptimized. Something still on the TODO list. [22:23:49] There's just so many debug lines that get conditionally compiled in that everything just slows down to a crawl [22:24:50] Yes I've seen that it dumps out a lots of logs. I tried to avoid to use it. [22:25:47] A lot of the #if DEBUG lines should simply be replaced by #if 0 [22:26:00] Or have some other way to be selectively turned on and off [22:26:30] Debug builds are useful. We've found some uninitialized memory and use after free issues with it in the past. [22:28:10] were indy91 and n7275 using single-threaded when testing your scenario? I know multithreading is usually what people use [22:28:46] Indy tested it with single-threaded [22:28:47] There has been talks about going to multi-threaded AGC by default. They probably did. [22:28:55] hmm, okay [22:29:47] Yes that was my first idea. Lack of Multi-thread is the main defficiency of my branch. [22:31:19] I made all the peripherals depending on AGC timing, so at least these should run within the same thread as AGC [22:33:03] E.g. I'm not piling up counter requests, just have a flag for plus and another for the minus request. As in the real hw, where you have two flip-flops for each counter register to take care of incoming requests. [22:34:33] yeah for sure [22:35:39] But to make that work, you have to guarantee that the device is in perfect sync with the AGC. [22:35:45] that's one of my favorite AGC quirks -- that if both flip-flops are set, it only executes a single count cycle, and the control pulses for both happen at the same time [22:36:00] which either makes it do nothing, or one of the two will win out :P [22:36:21] right, yeah [22:40:25] You might be able to fix it if you put a lock on it. Not sure what the performance implications would be if you have multiple subsystems lock the AGC during a timestep. [22:40:52] Mike, You surprised me :) I always assumed that there is some prioritazitaio [22:41:38] prioritization going on within plus and minus signal, but I looked up the schematics for a PIPA signal and you are right! [22:43:18] it works out that MCDU and SHANC are supersets of PCDU and SHINC, respectively [22:43:33] so if both are pending for those types you will just get an MCDU or a SHANC [22:43:39] PINC and MINC do manage to cancel each other out though [22:44:27] well, almost [22:44:32] they'd turn +0 into -0 [22:44:35] but that's it [22:44:50] the PONEX and MONEX control pulses combine to just put -0 on the write lines [22:46:30] Though I believe everybody involved in the development was tried to avoid such situation. [22:47:41] Maybe some extreme overload could lead to such collision. [22:48:16] yeah there would have to be a glitch or something for it to occur [23:04:16] See you all! [14:37:12] morning [14:38:37] saw you guys were discussing SPSDK yesterday [14:43:41] Yeah, we did for a little bit. [14:44:19] I was curious if everything was licensed properly and maybe consider doing a standalone release of it with our updates. [14:47:38] I actually got intrested in its history a few weeks ago, and after finding the same thread from MSC I managed to find Radu094 on facebook [14:48:17] he's still around, and had no idea that Orbiter or NASSP were still going [14:48:59] making SPSDK a stand alone/submodule would be really cool [14:49:57] It already is. Just that the last release was by Radu in like 2005. [14:50:28] Probably not much will be updated. But it might raise interest and let people know it's still working. [15:27:56] hey guys [15:28:01] Hey [15:28:09] hi [15:29:48] how's it going? [15:31:26] still working on Apollo 5, fixing some stuff for the abort modes it has [15:33:55] good morning [15:38:17] hey Alex [15:42:13] ok, Apollo 5 suborbital abort works. Now just need to test contingency orbit insertion again and I'm done with this branch I think [15:49:23] and I guess thats it for LEMSaturn? [15:51:20] LEMSaturn is gone :D [15:51:28] completely deleted [15:51:41] so Apollo 5 is only possible with the docked stages now [15:51:52] it was a buggy mess anyway, no real loss [15:56:35] nice [15:56:59] the LEMSaturn class was all the Saturn systems integrated into a LM [15:57:03] in the LM project [15:57:19] that made the LEM.dll larger [15:57:25] right [15:58:00] speaking of larger, LM_VC.msh is now about 17 MB :D [15:58:08] haha [15:58:13] well not too bad [16:00:26] its all the switches/breakers/rotaries and screws that really make the file size grow [16:00:45] unavoidable I guess [16:01:06] yeah [16:01:20] and I have been trying to optimize the polygon count [16:01:39] ok, COI didn't work out so good, but only because S-IVB cutoff happened too early. [16:01:54] will try again with cutoff 10 seconds later [16:02:17] if it's too early then the LM needs to spend all its DV just to recover from the negative altitude rate [16:06:50] possibly ignorant question: is it our goal to eventually separate the launch vehicle and stage classes from each other and from the CSM? [16:09:15] a long term goal, yes [16:09:30] I've been testing stuff for that in the past [16:09:45] it's a bunch of work. But there are no real roadblocks [16:10:03] Dock stages while landed on a planet have only been supported since Orbiter 2016 [16:10:05] Docked* [16:10:23] So I started with a mission that doesn't hurt anyone if there are bugs, Apollo 5 [16:10:34] the next big step would probably be Apollo 7 [16:11:22] the Saturn class is just such a monster, with everything for the CSM and the Saturn stages. Would be much nicer to have them separate [16:13:43] okay, cool. [16:14:51] S-IVB/IU/SLA is one vehicle right now with Apollo 5 [16:14:58] I think I want to split up those as well [16:15:16] AS-203 comes to mind (didn't have a SLA, only a nose cap) and also Skylab [16:15:44] we would have a separate Skylab vessel and then above that our normal IU [16:16:58] and then the payload shroud and whatever comes above [16:18:08] or any other fictional or real payload [16:18:21] that becomes much easier if you just need to dock the stages together [16:18:37] that was one of my major interests [16:19:58] would also help with onboarding new programmers to help us with the code more modular and compartmentalized [16:22:52] and for the long term, after we support the Apollo and Skylab programs, what comes next? [16:23:05] well lots of fun fictional missions probably [16:25:37] I'm sure we could do a much better job with making things modular in the Saturn class [16:27:40] but if docked stages work, all the better [16:31:44] yes that's what I ment. modular in the docking sense, not just in a class sense [16:33:31] there are a few "future use of apollo hardware" reports from the late 1960s that I occasionally drool over [16:33:58] but we have a lot of work before then [16:36:22] morning! [16:40:16] Hey Mike [16:40:20] hi Mike [16:44:54] hey [16:45:34] n7275, well anything that fits in a Saturn IB (consisting of docked stages) can soon be lifted to orbit [16:46:32] awesome [16:46:51] the exact docking port positions might still need fine tuning [16:47:18] it's best to use the real separation plane coordinates, but I don't always know where that is relative to the meshs [16:47:27] and our meshes might not all be that accurate [17:15:47] indy91, I finished P12 last night and the rest of bank 30 was FINDCDUW [17:16:18] which had a number of small differences -- some of which could possibly have gone into Sundance 302 or 306, but it is hard to say [17:16:21] ah so there is FINDCDUW. Not really a surprise I guess, it has ascent and descent programs [17:16:36] oh wait, is findcduw only used for ascent/descent? [17:16:43] in Sundance yes [17:16:46] I guess [17:16:49] oh perfect, then they didn't fix it :D [17:17:10] well, that was just going by what we saw with P40 etc [17:17:24] the "cross product" steering in Luminary uses FINDCDUW [17:17:28] but not in Sundance [17:17:49] right! [17:18:05] hmm [17:18:15] P41SPOT does call INITCDUW [17:18:41] but I don't see any direct calls to FINDCDUW here [17:19:09] what does INITCDUW do? [17:19:35] sets UNFV/2 and UNWC/2 to UNITX [17:19:37] and that's it [17:19:48] ah [17:20:02] ah it's in the GSOP [17:20:12] oh! where? [17:20:16] for Luminary [17:20:19] top of PDF page 166 [17:20:25] oh for luminary, yeah [17:20:42] https://www.ibiblio.org/apollo/Documents/LUM27_text.pdf [17:20:46] interesting note there [17:21:19] "...distinguishes the present routine from the old FINDCDUD Routine which was never used in the window control mode and still exists, along with FINDCDUW, in Program SUNDANCE." [17:21:23] I knew W was window [17:21:34] I guess I'm going to find FINDCDUD somewhere in here too [17:21:38] right [17:25:17] the P40s are calling some stuff unknown stuff in bank 42 [17:25:26] so I guess there is still room for surprises there [17:25:42] I just barely started the beginning of bank 31 last night [17:25:58] which has extremely strange code [17:26:06] that I think might be an extremely early P68 [17:26:53] what makes it strange? [17:29:41] one of the first things it does is set FAILFLAG [17:29:52] and then it abuses UPFLAG to set a bit in a word that is not a flagword [17:30:44] what is failflag? [17:30:48] no idea [17:30:57] ah, Sundance only [17:31:45] it does set SURFFLAG though [17:31:53] which is the only thing right now that is making me think maybe it is P68 [17:32:02] sounds reasonable [17:32:14] oh and it has two displays [17:34:00] let me find them... [17:34:50] okay so it does V06N43 [17:34:57] which is the same as Luminary's P68 [17:35:03] earliest GSOP doesn't even have a P68 [17:35:56] and then immediately after V06N43 it does V02N65 [17:36:04] I think? [17:36:21] oh no no [17:36:27] nevermind [17:36:42] after V06N43 it does checklist code 501 [17:37:09] V50 N25 [17:37:39] right [17:38:10] not sure what checklist code 500 is [17:38:11] 501* [17:38:30] maybe tells the astronauts to switch off something [17:38:34] LR or PGNS or os [17:38:37] so* [17:39:26] code 500 is switch LR to position 1 [17:41:30] ah, could be [17:42:07] which would make sense for P68 [17:46:53] yeah [17:46:56] will find out more tonight [17:47:09] only 3 banks left before disassembly is essentially complete :D [17:51:57] nice! some of the most exciting part still ahead [20:05:08] and some of the least exciting bits. I'm going to have to learn a lot about the phase logic untangle the restart tables, haha [20:05:23] ascent code even uses different phases from Luminary [20:11:25] I insist on restart protection :P [20:11:52] hehehe [20:11:58] it may not be perfect but I'll try [20:12:03] oh! [20:12:09] something else I wanted to tell you [20:12:11] bad news for P12 [20:12:30] remember how it was referencing some random constant in bank 26 that couldn't possibly have been right? [20:12:39] so we were thinking there must have been some sort of offset? [20:12:43] yeah [20:12:52] well, FINDCDUW also uses a constant in that bank [20:13:01] and it's at the right address [20:13:09] so P12 may just have a bug there [20:13:24] same Sundance revision? [20:13:43] no, 292 and 302 [20:13:57] so there could been two changes that cancel each other out [20:14:02] but that is unlikely [20:14:25] right [20:14:44] mystery/wrong constant is at 26,2420 [20:14:58] FINDCDUW uses 2PI/8 which is at 26,3360 in both 292 and 302 [20:15:05] well, I guess it goes to the list of things we have to look at again after you finish disassemblying [20:15:11] yeah [20:15:50] R60LEM is also at the same place in 292 and 302, at 26,2103 [20:16:08] and 306 [20:19:59] hi [20:20:08] as long as we don't find any of this type of issue in programs that actually were used on Apollo 9... [20:20:10] hey Jordan [20:27:16] AlexB_88 Check this https://1drv.ms/u/s!ApTRgF_OsQUFgVoiT_1f5KAGGJs-?e=77yuul https://1drv.ms/u/s!ApTRgF_OsQUFgVutSrHHiiav1CwT?e=qK4EPL [20:31:58] very nice [20:43:10] night! [12:54:04] hello [12:54:09] hey [12:57:18] started working on converting the Wiki over last night [12:58:17] I remember that we discussed using the Github wiki some time ago. Is it useful? [13:01:30] it leaves a lot to be desired.... [13:01:47] like no hosting of images [13:03:13] I'm just focusing on getting the articles and their images and formatting. where I end up putting them... [13:05:17] definitely something that needs to be done [13:05:37] speaking of things to be done. My Apollo 5 branch is done! [13:06:05] let's see how many files I forgot to include this time [13:07:18] lol. that's awesome. can't wait play with it [13:07:47] not that there is much to play really haha [13:08:05] it's as before, there is a T-1 hour scenario with a powered down LM etc [13:08:21] and then the T-60 seconds scenario which I definitely recommend to be used [13:22:34] yeah [13:29:18] it built, yay [14:30:17] legit wondering if I can get away with running Orbiter on my work computer right now... [14:30:49] hahaha [14:31:12] if you want to fly Apollo 5 you don't even have to be actively doing anything, just a "screen saver" [14:32:26] and after the LM separates from the S-IVB there is a 3 hour period where nothing happens :D [15:55:04] hey [15:58:08] hey Alex [15:59:32] morning! [16:00:03] indy91, I got thorugh a lot of bank 31 last night, and bring interesting news from the land of the lunar landing code [16:00:18] not sure if it's good news or bad news, but I certainly wasn't expecting it [16:01:19] at least it's not definitely bad news :D [16:06:03] hi Alex, hi Mike [16:06:39] Guenter! [16:06:43] okay there, IRC client was broken [16:06:45] hey n7275 [16:07:09] okay so [16:07:21] everything has been here so far [16:07:35] P64, P65, P66, P67 [16:07:53] throttle control routines are already almost all the way there [16:08:05] the tables are formatted completely differently which is interesting [16:08:06] bug! [16:08:10] the unexpected thing [16:08:27] so far, every single thing that is a padload for the descent in Luminary is hardcoded in fixed memory in Sundance [16:08:47] I haven't gotten all the way through so I don't have a full list [16:08:56] but at least HIGHCRIT, LOWCRIT, and ABRFG are [16:09:20] less work for me! [16:09:30] :D [16:10:13] I'm really curious if things like TLAND will be hardcoded [16:10:26] I hope not [16:10:32] and I very much doubt it [16:10:59] at most all the descent targets, maybe the ignition algorithm numbers [16:12:25] hopefully! [16:12:54] TLAND is very sensitive [16:13:07] more than a few minutes off and it will fail the ignition algorithm [16:13:16] that would be a terrible thing to hardcode [16:13:39] unless it's only a testing version of the descent programs [16:14:30] we will see! [16:14:38] maybe in a few days haha [16:14:51] progress has been very slow with all of the changes [16:15:26] I bet [16:15:46] won't get better until you are done with Sundance I' afraid [16:15:51] I'm* [16:15:53] heheh nope [16:16:06] I did confirm that the code I was talking about yesterday was a primitive P68 [16:16:18] but there's something else right after it and I have no ideas for that [16:16:33] almost made me give up on bank 31 and go to 33 until I recognized GUILDENSTERN [16:17:25] but there's some 78 mystery words between the end of P68 and the beginning of GUILDEN [16:19:28] that's a lot of mystery words [16:21:32] any idea what they do? [16:23:07] not at all [16:23:35] althogh the tail end does turn on the engine [16:23:48] *although [16:24:04] so could be very early ignition code or something like that [16:24:19] it will help if I can find something that calls it [16:34:59] right [17:00:31] Apollo 5 is done btw [17:01:00] oh awesome! [17:01:02] although my grand solution for the docked connectors (data between S-IB and S-IVB, S-IVB and LM) doesn't work [17:01:03] I might have to try it out :D [17:01:11] awww [17:01:21] but I don't think it breaks anything [17:01:41] only if there is no payload like a LM connected to the S-IVB is there any problem [17:01:52] I was just assemblying AS-201 [17:01:56] so that doesn't work then [17:02:23] so I have to fix it, but don't have to hurry [17:03:26] has some fun effects [17:03:37] the FCC doesn't recognize that it's still connected to a S-IB [17:03:44] so it defaults to S-IVB burn mode [17:03:48] oh boy [17:03:49] no [17:03:59] S-IVB orbital attitude control basically [17:04:08] so it tries to steer the whole Saturn IB with the APS :D [17:04:26] doesn't work so well [17:05:37] hehehehe [17:06:55] just tried the apollo 5 sceneriao [17:07:20] it does some odd things [17:08:18] looks like it's going to tip over upon loading the simulation, but the nosecone remains fixed in space [17:10:21] the nose cone behaves weird for me as well [17:10:39] sometimes it's not really there when I load the scenario [17:10:43] and then jumps into place [17:11:03] but I don't have that falling over problem [17:11:18] I have it quite badly with my AS-201 testing scenario right now [17:11:21] but not Apollo 5 [17:27:53] odd, it's like the leaning tower of Pisa [17:28:11] has flashbacks to AlexB_88 launching the LUT [17:28:58] https://www.dropbox.com/s/wil58jg7jpd3tl0/crash.png?dl=0 [17:30:01] hahaha I love that picture [17:31:15] one of the unintended effects when I tried to dock the Saturn to the ML :D [17:31:25] I did not try that [17:31:31] S-IB is standing on its own [17:31:32] well [17:31:34] for me anyway [17:32:36] looks like the S1C engines were gimballed quite sharply in that picture [17:33:01] dont even think they can do that in the latest version with the realistic limitsÉ [17:33:07] ?* [17:33:37] oh wow. someone broke the universe [17:34:16] I'll try messing with it again later, it might be me [17:35:03] yes there are gimbal limits now [17:35:19] n7275, other scenarios broken as well? [17:35:39] both, yep [17:36:20] both Apollo 5 scenarios you mean? [17:36:24] well I guess they have the same issue [17:36:38] AlexB_88, can you switch to the Orbiter2016 branch and try them? [17:36:48] just to see if the issue is on my end [17:37:50] maybe I need to adjust the mass used for the touchdown point calculation [17:37:58] sure, I am just finishing with the start switch and Ill switch to Orbiter2016 in a few mins [17:38:01] yes both apollo 5 sceneriaos [17:39:11] starting paused slowed it down a bit, but it still ends up with a vaguely westerly lean of about 20° [17:43:53] weird [17:44:21] I mean, the issue is likely the touchdown points, but I don't understand why it works fine for me then [17:46:28] and that's why I started doing the docked stages with Apollo 5 and not one of the missions that really matters for NASSP :D [17:49:32] hey now [17:49:36] Apollo 5 is the best mission [17:51:10] it's just not very interactive :D [17:52:27] building Orbiter2016 [17:52:31] what should I check? [17:52:34] I'm increasingly believing it's something on my end [17:53:10] AlexB_88, just start one of the Apollo 5 scenarios [17:53:17] and see if it nearly falls off [17:53:28] has a lean I mean [17:53:56] ok [17:55:04] hmm [17:55:07] looks ok [17:55:15] in the scenario from the WIP folder [17:55:27] right, that's good to hear [17:55:32] n7275, is yours leaning? [17:57:48] and if so, do you have this file: [17:57:54] Textures\Earth\Elev_mod\15\000699\001131.elv [17:58:44] I think Jordan was using a different texture directory at one point which didnt have the elev_mod [17:58:58] so that could be the issue here too [17:59:07] did we flatten LC-37B as well? [17:59:11] yes [17:59:27] if I take that file out, then its leaning for me too [17:59:36] ooh [17:59:40] that might be the issue then [17:59:47] 1131.elev covers all the LC-37s I think [18:00:12] and 34? [18:00:46] uhh yeah I meant 34 and 37 [18:02:08] btw the lover on top of the SLA panels only appear a few seconds into the session [18:02:13] the cover* [18:02:36] and doesnt seem "attached" to the vehicle [18:02:42] yes, it's weird [18:02:52] not sure what causes it [18:02:59] the nose cone is only defined in the config [18:03:14] maybe I have to create a VS project for it to work right... [18:03:53] I haven't given it touchdown points [18:03:56] maybe it's that [18:04:19] ya know what [18:04:50] its me [18:05:39] my textures directory is linked to my Orbiter 2016 directory [18:06:00] picardfacepalm.gif [18:07:26] indy91, I flew it up to staging, looks good [18:09:20] n7275, well it's probably the most advanced error you can make in setting up NASSP :P [18:09:42] we only recently added that to the installation instructions [18:11:11] I should've know. had the same problem with the new LM VC and new tower textures [18:11:48] the good news is, even with a lean the LV IMU now gets a good alignment [18:11:56] although 20° might cause some other issues... [18:12:51] I'll try launching like that later and let you know [18:31:18] great [18:34:57] indy91, I noticed you cannot hear the engine sounds from the S1B [18:35:12] probably since its a different vessel [18:35:36] I wonder if there is a way we can re-introduce the sounds somehow in the docked stages case [18:35:37] you mean the engine sounds of the S-IB? [18:35:40] in the LM [18:35:47] yeah [18:36:01] I'm sure there is a way, yes [18:37:16] not too important right now I guess but when we get to making the Saturn V docked stages [18:38:03] yeah [18:38:10] & CSM SIB [19:01:27] https://videos.space.com/m/aCgMcEEs/see-boeing-starliners-control-panel-in-virtual-reality?list=6DUiA9a3 [19:01:32] quite different from Dragon :) [19:04:47] wow, actual switches [19:07:06] definitely no shared type rating [19:09:43] ooooooooh [19:09:51] I'm looking at Luminary memos again [19:10:00] revision 12 [19:10:08] "A P65-P66-P67 testing program was deleted." [19:10:11] I wonder if Sundance has that [19:10:38] maybe your mystery words [19:10:44] could be! [19:15:47] but I'm not seeing where the descent targets were moved to erasable [19:17:27] I like this one "TLAND was moved into the W-matrix." [19:17:54] yes they are overlayed. That's why you can't do marks with P20 before landing on the Moon :D [19:19:38] just weird phrasing, "was moved into the W-Matrix" [19:25:36] hahaha [19:25:41] yeah [20:01:23] I want to launch AS-201, but LC-34 doesn't let me [20:01:52] LC-34 is stricter than LC-37 :D [20:04:54] hahaha [20:08:45] oh oh oh [20:09:15] that note about the P10/P11 padload TIG(AS) being deleted [20:09:27] that happened in rev 21 [20:09:55] but in rev 18 there is "The loading of TIG(AS) into TIG was deleted from P12." [20:10:05] so I may already know its address and just didn't know what it was [20:11:16] didn't we suspect that it was loading it to P12? [20:11:29] I didn't :D [20:11:34] maybe you mentioned it and I forgot haha [20:11:39] P10/P11 calculate the ascent TIG and as a service feature that is loaded to P12 [20:11:49] or did we have a similar case with the rendezvous programs... [20:12:17] 30,2010: 00006 1 EXTEND [20:12:17] 30,2011: 31423 0 DCA UE7,1422 [20:12:18] 30,2012: 53425 1 DXCH TIG [20:12:29] yeah right at the beginning of P12 there [20:12:36] something I didn't know being written into TIG [20:12:38] I bet that's it :D [20:13:33] yeah, nice feature [20:14:05] nice for the astronauts. Took them ages to do something similar for V90 [20:14:16] hmm, why do they call it a padload if p10/p11 calculate it? [20:14:21] or am I misunderstanding something [20:14:22] load the TIG of the next rendezvous maneuver for V90 so that you don't need to type it again [20:14:31] hmm [20:14:40] maybe it's a threshold time for P10/P11 [20:14:47] and then it gets modified? [20:14:56] hmm, maybe [20:15:03] I guess that will be another thing to learn [20:16:00] for AS-201 I'll add CM Block I and SM Block I as new VS projects I think [20:16:07] so that we can slowly develop those [20:16:21] eventually for Apollo 4 and 6 as well [20:16:46] finally liftoff with AS-201... [20:17:02] had to "wire" the S-IB thrust ok logic from the S-IB to the EDS in the IU [20:17:11] LC-37 didn't check those [20:21:36] heh [20:21:51] well, I never implemented that LC-37 checks it [20:24:14] ah, Luminary 34: "Two new pad-loads, LOWCRIT and HIGHCRIT, were defined for the throttle program" [20:24:18] so there's two of them [20:26:23] oh so late [20:26:31] I only checked the very early Luminary memos [20:26:37] heheh [20:29:38] no AS-201 launch vehicle operational trajectory available, which is a bit unfortunate [20:35:32] :( [20:40:31] I can derive the values I need fairly closely from the flight evaluation report [21:02:47] ooooooooooooh found something interesting in the luminary memos [21:03:31] "Due to a recent change in the Display Routines (the XDSPFLAG is set by each MARK display) the extended verb displays of R63 were changed to normal displays so that subsequent R60 displays would not be locked out." [21:04:13] in June, between Sundance 292 and 302 [21:04:20] I wonder if that is related to the mystery routine in fixed-fixed [21:29:41] could be [21:31:11] night! [15:57:50] morning! [15:58:04] indy91, new fun discoveries in the landing programs last night [15:58:27] hey [15:58:33] nice [15:58:49] so the code at the begining of the bank is definitely the predecessor to P68 [15:59:01] but it is not a program in the way P68 is [15:59:32] it turns out that in Sundance, once you get into P65 or P66 [15:59:34] as indicated by that early GSOP, which had no P68 [15:59:42] the V06N60 display is flashing [15:59:56] and if you PROCEED on it, it cuts your engine and starts performing the P68 calculations immediately [16:00:24] oh interesting [16:00:48] I guess they found that a bit unsafe [16:00:51] hahaha yeah [16:00:58] better only cut the engine with the specific button for it [16:01:06] otherwise a new way of doing it [16:01:09] a nice* [16:01:46] really hope we get it working [16:01:49] I'm very close to the end of bank 31 [16:02:04] and so far everything has been here -- an early version but the guidance equations are not too different [16:02:19] at this point I don't see any reason why we wouldn't be able to land it [16:02:33] great [16:03:03] although it's tempting to try that or P10/P11 first, I think it makes more sense, once you come up with a Sundance build, to fly Apollo 9 and try to have it work normally [16:03:32] lol yeah for sure [16:03:44] that should help us fix all the remaining general issues [16:05:30] I'm excited :D [16:06:45] yeah, I better don't start any other month-long projects right now [16:07:18] you could probably start a couple of weeks project pretty safely [16:07:38] I will probably finish the disassembly early next week [16:07:57] and then it's going to be another big effort to turn that into source code that can be assembled [16:08:15] much less big, but still involved :) [16:13:23] I'm doing the eternal task again of moving functions out of the LVDC that don't belong there [16:13:27] this time, mission time [16:14:07] the ground computer does a GMT sync with the LVDC a few minutes before launch and that should be it [16:14:48] I implemented that essentially, although to not break old scenarios I'm doing the time sync just before GRR [16:15:08] so now the LVDC doesn't need to know about any external mission time anymore [16:15:25] I still have 8 functions that I want to remove [16:15:38] although 2 of them are just to compare the LVDC state vector with the actual [16:15:51] nice :D [16:17:35] 2 more are mission specific things that I can change to be a LVDC variable [16:18:38] then it's some legacy code, we for some reason have different Saturn stages called LAUNCH_STAGE_SIVB and STAGE_ORBIT_SIVB [16:19:22] LVDC code still converts it from launch to orbit [16:19:37] not sure how much code is still left that needs that differentiation... [16:19:47] but it's that sort of code I always have to deal with :D [16:21:05] uhhh interesting [16:21:45] LAUNCH_STAGE_SIVB prevents more than 10x time acceleration, STAGE_ORBIT_SIVB doesn't [16:22:22] EARTH_ORBIT_INSERTION event is set when it becomes STAGE_ORBIT_SIVB [16:22:44] that is relevant for the Checklist MFD. So I definitely need to come up with some stuff for that [17:08:11] thewonderidiot, did you have P70 and P71 yet in Sundance? [17:08:53] not yet [17:08:59] they're in the back half of bank 32 [17:09:10] the insertion velocity logic for that is totally different between Luminary 69, 99 and 116, so I wonder if it's a 4th variant of it :D [17:09:19] hahaha almost certainly :D [17:09:46] I haven't decided what I'm going to do next yet [17:10:04] I could do bank 32 and just start at address 32,2671 [17:10:12] which is the entry point for P63 [17:10:24] theoretically everything before that is P10/P11 [17:10:29] and then bank 33 is mostly servicer stuff [17:10:55] good morning ggalfi :) [17:10:58] Hello! [17:11:25] We are close to sunset here :) [17:11:36] hey [17:12:07] I don't think there was an AGC version called Sunset :D [17:12:12] or was there? [17:12:28] hahaha not that I know of [17:12:49] but there were hundreds of offline programs [17:13:07] so if one was called BATMAN, then I would be surprised if SUNSET was not chosen for something at some point :D [17:13:18] Maybe it our task to develop it :) [17:13:37] maybe SUNSET would be a better name for Terminus, haha [17:14:01] renaming doesn't fix bugs though :P [17:14:07] ssshhhhh [17:14:10] I'll fix them someday [17:14:36] just distract me with other software [17:15:48] I'd like a look at the LVDC software right now, how it updates the various times it keeps around... [17:16:05] yeah that would be super great [17:16:49] I should check in with Ron... he said the lawyer had an update for him just before the pandemic hit and their offices closed [17:17:18] I've been reading his Github commits [17:17:43] although I haven't tried anything with the PTC yet [17:17:45] he's been going to town on the PTC, haha [17:18:04] got as far as updating my local Virtual AGC repo [17:21:28] https://github.com/virtualagc/virtualagc/blob/master/yaASM.py/sample-1967.lvdc [17:21:37] the variables I am interested in even appear there [17:21:45] but not where they are updated... [17:22:48] Wow, you got some scans of the real LVDC source code? [17:23:13] yep [17:23:22] except [17:23:22] for the AS-206 Restart Alternate Mission, and it's a development listing that doesn't assemble without errors.... but yeah [17:23:43] non-US folk aren't allowed to look at it [17:23:52] maybe [17:24:00] well, right now that's the case :D [17:24:04] I close my eyes :) [17:24:11] yeah. we're trying to figure it out [17:24:15] what I linked is a small part of it [17:24:23] some examples which are harmless [17:25:04] and not scary missle guidance code [17:25:59] I'm sure we can eventually use that code to fly Saturn IB ascents [17:26:24] if it becomes freely available [17:47:32] Indy I still wasn't able to find why you had issues with the agcio and why I haven't. I'd like to make sure that I follow the same build procedure as you: I checkout the branch, do a project clean, and build the Release version.Is that the correct way? [17:49:40] I don't always do a project clean, but yes [17:49:51] and I usually rebuild instead of build if I switch branches [17:50:19] but that's the same thing with project clean, right? [17:51:00] I guess what we have to find out is why I get an additional time increment that shouldn't be there [17:53:31] One of my suspects is that one module which has some interaction with virtualagc is not rebuilt and and addressing wrong part of the agc state struct. [17:55:16] I'll make commit with some debug logging of agc status right after initialization. Maybe it reveals something. [17:55:27] sure, I can try that then [18:04:34] BTW, do you have any problem with DEDA initialization? When I load my test scenario it displays slightly different numbers as when it was saved. When I reread the AGS register, it shows again the correct figures. The strange thing is that I haven't touched AGS and DEDA related code. [18:07:44] yes, I get that [18:08:04] always been getting it. Some bug, either DEDA or AEA [18:08:40] the development history of the DEDA is: I couldn't get anything to work, until I got it to work, and it was working so well that I never touched it again [18:08:49] but I guess it isn't quite perfect [18:12:30] It's ok, I'm just trying to identify the points where wrong addressing could happen. [18:14:57] If you have a C or C++ code which works finely on one machine and works badly on another, it is likely due to some addressing issue. [18:19:00] or something missing proper initialization [18:19:11] that's what I had with RTCC code a bunch of times lately [19:09:20] ah P68 wasn't added until Luminary 31 [19:10:24] yep [19:10:35] PCF 470 [19:10:37] PCR* [19:12:27] I'm gonna have to go through all of these luminary memos more closely [19:12:40] to see if I can extract names of constants and erasables and things [19:13:21] also don't forget the SCB memos, that's what I was just looking at [19:19:08] yeah [19:19:11] I wish we had more of those [19:19:43] I was actually just thinking the other day if we could find more padloads in other boxes at NARA [19:20:13] like [19:20:14] https://www.ibiblio.org/apollo/Documents/padload_13_cm.pdf [19:20:37] that padload is encapsulated in 70-FS55-77 to the ASPO, from the Flight Support Division [19:20:49] I wonder if there is a box for that series of memos [19:23:35] the neil armstrong collection at purdue has several SCB meeting memos [19:23:43] from exactly the right timeframe [19:24:07] June 6, June 27 [19:24:35] ah, we have the june 27 one but not june 6 [19:24:37] well, good luck getting them :D [19:24:41] heh yeah [19:24:53] some earlier padloads would be nice [19:27:30] if NARA has CSM and LM Data Books then it will also have padloads [19:29:26] it has a late CSM one [19:29:56] won't have early padloads [19:31:08] I need to ask Debbie if her copy of the LM data book has anything [19:31:16] we know it at least has 13 [19:32:27] an Apollo 9 padload would be very helpful [19:36:53] it would be super duper helpful [19:36:56] I'll email her [21:24:20] night! [14:47:50] hey [14:59:00] hey Alex [15:34:46] attempt #523 to implement the LVDC minor loop support routine [15:34:52] not getting anywhere yet again [15:34:55] haha [15:35:00] it just requires too many changes at once [15:35:22] the result would be smooth steering, especially during the pitch maneuver after launch [15:35:41] right [15:35:56] but the way it works requires certain code to be called regularly [15:36:36] so I'd have to make the LVDC more like an emulator, calling it not once per timestep, but e.g. 100 times per second [15:38:04] https://www.dropbox.com/s/4ctggu3pb3t4rxi/Screenshot%202020-06-13%2009.35.10.png?dl=0 [15:38:14] panel 5 & 6 are working [15:38:51] looks great [15:41:38] I just have one issue with the DEDA displays [15:42:13] I can enter data into it but I cannot get it to display any read-outs [15:43:25] actually, I cant enter data into it either [15:43:47] say I do 400+10000, when I press enter I get OPR ERR [15:44:30] in the 2D panel that happens if you didnt press CLR in between entries, but I did that [15:44:34] maybe the Clear didn't go in [15:51:03] which buttons do work? [15:51:08] the numbers? [15:58:49] all the buttons work [15:59:48] then it's just part of the functionality, the computer interaction, that doesn't work [16:01:04] you use a PANEL_REDRAW_NEVER for it [16:01:09] is that what you want? [16:03:19] one thing you can check [16:03:20] void LEM_DEDA::ClearCallback(PanelSwitchItem* s) [16:03:34] it has code for the button being pressed, but also it being release [16:03:41] maybe the button isn't being released rightz [16:03:42] right [16:06:13] ok Ill take a look [16:07:53] operator error is entirely DEDA [16:07:56] not AEA [16:08:11] so if it gave you the error when you pressed enter [16:08:15] if (State == 9) [16:08:18] then that isn't true [16:18:34] morning! [16:19:35] hey Mike [16:20:26] finished bank 31 last night :D [16:20:45] and confirmed the weird chunk of code is definitely the P65/P66/P67 test program [16:21:23] ah fun [16:21:54] it starts from engine off, does ullage, turns on the engine, and drops you straight into P65 [16:21:59] lol [16:22:13] after initializing all of the needed erasables [16:22:47] hmm [16:22:56] where would you start that trajectory wise [16:23:04] P65 from orbit? [16:23:09] but if not from orbit, why ullage [16:23:34] not sure [16:24:39] https://github.com/thewonderidiot/sundance/blob/master/b5_292.disagc#L1214 [16:31:30] any idea how the test program would be started? [16:35:10] and what are you doing next? :D [16:37:34] we can start it with V30 at least [16:37:46] that should be easy [16:37:56] and I'm doing bank 32 next I think [16:38:11] but skipping over P10/P11 and going to the P63 entry point [16:44:18] how different can P63 really be :D [16:48:13] hmm, so what am I going to do. Probably revert all this LVDC stuff I just did... [16:50:20] and just going to do some reorganizing without new features first [16:57:53] ahh too bad on LVDC [17:01:16] one of the changes where I have to change everything for it to work right [17:02:58] can I get the emulator yet? :D [17:13:36] oh yeah the emulator is all in virtualagc [17:13:42] just not anything to run on it :P [17:45:50] hmm [17:45:57] another new flag [17:45:59] VINHFLG [17:47:14] oh and right next to ti HINHFLG [17:52:05] H and V [17:52:08] maybe LR related [17:52:20] inhibit for incorporating height and velocity data? [17:52:49] the LRBYPASS flag doesn't appear to exist [17:53:01] so maybe these two are that, just per channel [17:53:06] also, found TLAND :) [17:53:15] E4,1420 [17:53:17] so not hardcoded [17:53:26] V57 is called "Set Altitude Inhibit" [17:53:45] aha! [17:53:54] V85 to V87 [17:54:25] hmm? [17:54:38] V85 is "reset velocity inhibit and override" [17:54:56] for what? the extended verb table doesn't have V85 to V87 in Sundance 306 [17:55:07] oh [17:55:09] 43,2054: 02706 1 TC V82PERF [17:55:09] 43,2055: 02716 0 TC V83PERF [17:55:10] 43,2056: 02757 0 TC R32 [17:55:10] 43,2057: 02120 0 TC ALM/END [17:55:11] 43,2060: 02120 0 TC ALM/END [17:55:11] 43,2061: 02120 0 TC ALM/END [17:55:12] 43,2062: 02120 0 TC ALM/END [17:55:12] 43,2063: 02724 1 TC V89PERF [17:55:13] 43,2064: 02733 1 TC V90PERF [17:55:19] well that's what the Systems Handbook said [17:55:22] hahaha [17:55:29] interesting [17:55:38] what does V57 do [17:55:44] let's see [17:55:45] and 58 [17:56:28] neither exist [17:56:42] haha [17:56:50] Systems Handbook has them as well [17:56:55] maybe they were disabled in 306 [17:57:02] hmm, could be [17:57:03] to make sure they weren't used during Apollo 9 [17:57:44] well if they're just setting bits we can do that the hard way :) [17:58:17] we will have to if we want to try lunar landings [17:58:36] if? :D [17:59:40] just is less convenient haha [18:00:26] we will have to test if V57 is enough to also allow LR velocity data [18:04:44] hmmm [18:04:55] there's a vector stored in bank 31 [18:06:14] that it P63 is loading, multiplying with REFSMMAT, and then storing (I think) in WM [18:06:19] any idea what that might be? [18:06:42] yep [18:06:48] rotation of the Moon [18:06:58] that's what WM is at least [18:07:16] and I guess WM is in guidance coordinates [18:07:20] so it gets transformed [18:07:31] aha [18:07:34] so the vector is [18:07:51] 0.0, 0.006977487, 0.0 [18:08:00] where I don't know the scaling of the middle number [18:09:06] that's either the rotation rate itself or multipled with the radius of the Moon [18:09:31] hmmmmm okay interesting [18:09:32] let's see [18:09:57] I think equivalent to MOONRATE? [18:10:22] yes, we have a winner :D [18:10:29] it's scaled slightly differently [18:10:33] E-7 B+18 [18:10:37] instead of E-7 B+19 [18:12:26] hey, I knew something [18:13:13] :D [18:13:17] thanks! [18:13:29] there will be many more such questions in the coming days as I try to work differences out haha [18:13:30] I guess it's similar to GUIDINIT [18:13:37] in Luminary [18:13:45] yeah, GUIDINIT doesn't exist in Sundance [18:13:50] so that explains what I'm seeing here [18:14:04] the P65/P66/P67 testing program also does this calculation [18:15:40] if it bypasses the normal P63 ignition stuff then it has some setting up to do, yeah [18:16:02] multiplied with the REFSMMAT is interesting [18:17:16] might be one of the limitations where the REFSMMAT doesn't have to be exactly the guidance coordinate transformation, but has to be close neough [18:17:28] there was a memo from Don about that I think [18:17:41] it's the same for Luminary of course [18:19:07] ah [18:19:08] https://www.ibiblio.org/apollo/Documents/LUM81_text.pdf [18:20:24] ah, nice [18:20:32] hmm, that specific thing isn't mentioned there [18:21:09] ah, because WM is in platform, not guidance coordinates [18:21:22] so the REFSMMAT is exactly the right conversion [19:03:12] hmmmm [19:03:15] DDUMCALC is very different [19:04:39] oh [19:04:45] there may be more hardcoded padloads here [19:06:37] yes okay [19:07:17] ignition algorithm? [19:07:42] yeah [19:07:57] VIGN, RIGN*, KIGN* [19:08:05] look like they are all hardcoded here [19:08:06] normally padloaded [19:08:16] not a big deal [19:08:27] more work for me, less work for you :D [19:08:30] haha [19:08:33] they are mainly a function of LM mass [19:09:32] as they will probably be reasonable values, they will work [19:10:35] yeah so far all of the hardcoded ones have been very similar to or the same as the example padloads shown in https://github.com/virtualagc/virtualagc/blob/master/Luminary069/PADLOADS.agc [19:11:06] scaling might be different [19:11:14] https://www.ibiblio.org/apollo/Documents/LUM34-CS_text.pdf [19:11:17] see revision 28 and 29 [19:11:40] haha [19:11:43] rescaled in 28 and then again in 29 [19:12:05] July, yeah, so Sundance will probably have 1/KGNX and KIGNV [19:12:48] and that explains why this interpretive chunk is all jumbled up from what it is in Luminary [19:14:06] did I even use those example values from the Luminary 69 listing [19:15:44] hahaha [19:15:56] no [19:16:04] I think I just used the Apollo 11 values [19:16:09] at least in the padload worksheet [19:24:58] alright so now I need to untangle the interpretive code in both Sundance and Luminary [19:25:03] I assume they're doing the same calculations [19:25:06] just at different scalings [19:26:06] if it has all the same variables, just in fixed memory, then probably yes [19:26:31] so what would KIGNY/B8 be called in Sundance... [19:26:49] just KIGNY I guess [19:28:18] does the value work with that scale factor? Or is the calculation scaled entirely different [19:28:55] not sure yet [19:29:02] I'm working out which one is which before I figure out scaling :D [19:29:16] haha [19:30:37] okay [19:30:45] well I think I worked it out [19:30:50] and they appear to be in a reasonable order [19:31:03] 32,3123: 00417 0 VIGN [19:31:04] 32,3124: 16641 0 [19:31:04] 32,3125: 77736 0 RIGNX [19:31:05] 32,3126: 63511 1 [19:31:05] 32,3127: 77126 1 RIGNZ [19:31:06] 32,3130: 65060 1 [19:31:06] 32,3131: 71463 0 1/KIGNX [19:31:07] 32,3132: 46314 0 [19:31:08] 32,3133: 77777 0 KIGNY [19:31:09] 32,3134: 74571 1 [19:31:10] 32,3135: 76647 0 KIGNV [19:31:11] 32,3136: 77777 0 [19:31:50] 1/KIGNX seems reasonable because Luminary multiplies by KIGNX/B4 while Sundance divides by 1/KIGNX [19:33:21] now, scaling [19:35:21] VIGN, RIGNX and RIGNZ look about the same [19:38:08] yeah [19:38:17] the others not so much, even if I apply the right scale factor... I think [19:38:43] there's essentially no shifting going on [19:39:02] so they are scaled the same as VGU and RGU, I think [19:40:12] ah [19:41:06] does that help? [19:41:34] only if I knew how those are scaled :D [19:41:39] hahahaha [19:41:41] yeah [19:41:44] I was hoping you would know :D [19:41:46] let's see [19:42:17] night! [19:45:41] KINGNY and KIGNV are not in meters and meters/second though [19:45:46] KIGNY* [19:46:06] hmmmm [19:46:07] yeah [19:46:10] they're scalars [19:46:15] uhh [19:46:16] so the math is [19:46:18] well, not entirely [19:46:28] they are basically made up factors [19:46:31] yeah [19:46:49] let me write out the equation as implemented [19:49:17] they should have the same scaling as VIGN and RIGNX/RIGNZ [19:49:23] or at least work as conversions [19:50:38] (RIGNZ - RGU+4) + ((RGU+2)^2 * KIGNY) + ((RGU - RIGNX) / 1/KIGNX) + ((|VGU| - VIGN) * KIGNV) [19:50:46] no, I meant that RGU and RIGNX/RIGNZ have the same scaling [19:51:15] yes definitely [19:51:55] actually let me finish that there's a bit more math [19:52:42] looks like in the GSOP [19:52:49] (((RIGNZ - RGU+4) + ((RGU+2)^2 * KIGNY) + ((RGU - RIGNX) / 1/KIGNX) + ((|VGU| - VIGN) * KIGNV)) << 7) / (VGU + 4) [19:53:02] er, that << 7 should be >> 7 [19:53:52] so... does that tell us anything about KIGN* [19:54:26] KIGNY should have the opposite sign of RGU? [19:54:52] that gets too large though... [19:55:54] B0 comes close for KIGNY [19:56:23] no wait, I am confused [19:56:55] when the padload document says "SF 18" [19:56:58] what does that mean? [19:57:29] that means for my padload worksheet [19:57:39] =C227*100*2^-18 [19:57:48] C227 being the cell with the engineering value [19:57:49] -410s [19:57:58] 100 for conversion to centiseconds [19:58:17] result is the AGC value to be converted to octal [19:58:55] aha, thanks [20:01:03] so for KIGNV/B4 [20:01:14] changing that to -22 to account for the "/B4" gives a reasonable number [20:02:22] wait no I'm mixing numbers together [20:03:18] would be engineering value -384 seconds [20:03:20] close enough [20:03:46] uhh [20:03:51] no [20:04:01] B4 is not factor 4 :D [20:04:02] 1536 [20:04:17] hehehe [20:04:58] 1536 is too far off [20:05:13] maybe it is just factor 4 [20:05:41] that would work ok [20:06:14] so for Y then [20:07:38] very different octal [20:07:45] yeah [20:08:11] there is of course also the additional factors in Luminary [20:08:20] (RIGNZ - RGU+2)/16 [20:08:28] well, (RIGNZ - RGU+4)/16 [20:11:24] okay so it's E-6 B16 in Luminary [20:12:16] oh E-6 [20:13:29] -2.4770341207 E-6 B16 [20:13:36] gives the correct octals for Apollo 11 [20:13:54] KIGNY? [20:14:01] yeah [20:14:27] yes [20:15:05] hmm yeah [20:15:13] not seeing how to get to a reasonable number for Sundance from there [20:19:32] same [20:20:28] alright I put in some close-ish placeholders [20:20:34] we can revisit in the future if we want [20:20:51] whatever the scaling actually is, the octals must be right :D [20:21:14] I can also see why they changed the scaling [20:21:33] with the octal varying widely [20:21:44] yeah definitely [20:22:31] oh DDUMCRIT is much larger [20:22:48] +20 where Luminary has +8 [20:28:14] made it more efficient maybe [20:28:19] GSOP has it in two equations [20:28:45] oh [20:28:59] I read DDUMCALC not DDUMCRIT :D [20:29:24] that will be the convergence criterion [20:29:34] 0.08 seconds vs 0.2 seconds [20:29:45] still not super larger [20:46:58] good night! [00:17:35] indy91, bad news -- I think there is a chunk of code that moved from bank 36 to bank 32 between Sundance 292 and 306 [00:17:42] which means with our mix of modules we're completely missing it [00:17:55] and it is needed for P40 and P47 [00:18:16] so we may have some work to do to put together a replacement [00:23:38] here's what I know about it [00:23:45] it's ~16-20 instructions [00:24:03] by which I mean "words" -- it's entirely interpetive [00:24:53] in Luminary rev 17, P40 and P47 were both modified to use MIDTOAVE [00:25:13] in Sundance, they both use this function instead [00:25:25] so it is performing integration [00:26:14] so we just need to figure out the correct incantation of the integration program for them to use [00:28:33] also where I'm saying "P40" I really mean "BURNBABY" [00:37:57] yes, it is definitely integrating, and it is definitely staying in this routine until integration is complete [00:39:23] so essentially we just need to figure out the parameters for integration, which integration routine to use, and then what the outputs they are expecting are [07:54:10] thewonderidiot, sounds like the most difficult challenge in Sundance so far [07:54:24] yeah [07:54:31] I'm feeling confident that we can figure it out though [07:54:49] I'm pretty sure it's just setting up the inputs to INTEGRV and putting the outputs in the right places [07:55:13] specifically, it's the state vector integration to TIG-30, and the one done at the beginning of P47 [07:55:35] yeah [07:56:03] something like MIDTOAVE in the GSOP [07:56:12] how does Colossus do it? [07:56:50] yeah, this code was replaced with a call to MIDTOAVE in Luminary 17 [07:56:59] Colossus also uses MIDTOAVE unfortunately [07:57:18] ah [07:58:08] how does Sunburst do it? :D [07:58:48] ohhhhhh you know what I didn't even think to look [07:58:48] uhh [07:59:12] where would this even be in Sunburst [08:00:23] mm, Sunburst doesn't even have INTEGRV [08:01:20] looks a bit like specialized code in each mission phase [08:01:36] yeah [08:02:01] Sunburst has MIDTOAVE :D [08:02:19] haha [08:02:22] but that's not what we want :D [08:02:28] https://www.ibiblio.org/apollo/listings/Sunburst120/INTEGRATION_INITIALIZATION.agc.html#4D4944544F415645 [08:02:54] but maybe this is somewhat close to what Sundance 292 does? [08:03:10] no, I don't think so [08:03:18] unfortunately the code is too different [08:05:02] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/INTEGRATION_INITIALIZATION.agc#L240 [08:05:53] I assume the settings we need are LM, precision, no W-matrix [08:06:03] do we want permanent update? I think we do [08:06:08] yep [08:06:44] yeah so, there's two entries to this function [08:06:58] as far as I can tell the first stores MPAC into TDEC1, while the second assumes it's already there [08:07:34] then it should maybe just be storing Q, calling INTSTALL, setting all of the flags we want, then calling INTEGRV [08:08:07] and then I need to figure out if they want their outputs in the default places or somewhere else [08:08:09] or if they care [08:08:24] at the very least this sounds very testable. Doing various burns and look if the post burn onboard state vector is right [08:08:51] yeah :) [08:09:11] I was very worried for a bit because bank 36 shifted around a *lot* from the perspective of P70 and P71 [08:09:30] but I'm pretty sure it's just this we're missing [08:09:39] and while it's critical it's also not hard to replace [08:09:42] I hope so [08:09:55] so this would basically be a reconstruction of how it worked in 292? [08:10:16] getting to the 306 version might would be too difficult [08:10:19] I strongly doubt that this changed between 292 and 306 [08:10:25] oh [08:10:43] it's just that they added stuff to bank 36, and this ended up getting moved to bank 32 to make space [08:10:54] ah, now I get it [08:11:01] .loggingstatus [08:11:37] I just suck at refreshing the page where I had the log open I guess [08:11:48] hahaha [08:13:15] so we've got some work to do, but it should be fun :D [08:13:24] the GSOP doesn't help much [08:13:30] yeah the GSOP is useless lol [08:13:39] I'm not even sure TIG-30 is correct [08:13:54] MIDTOAVE says 29.9? [08:14:42] yeah, 29.9 I guess [08:14:50] Sundance does: [08:15:01] TDEC1 = TIG - 29.9SEC [08:15:22] also SAVET-30 = TDEC1 [08:15:37] then calls an ENGINOF routine [08:15:56] then goes to the appropriate program spot [08:16:14] P12, P40, and P42 cal STCLOK2 to start the clock task [08:16:26] then all programs perform this integration to TDEC1 [08:16:40] after it returns, it checks the current time against what is in SAVET-30 [08:17:05] and if it passed SAVET-30, then it issues a 1711 program alarm [08:17:41] right [08:18:55] 1711? [08:18:59] yep [08:19:01] Luminary doesn't even have that [08:19:06] is that the same as 1703? [08:19:30] uhh, not in Sundance [08:19:41] GSOP section 4, page 531 [08:22:04] interesting [08:23:14] Colossus and Luminary only have 1703 for that [08:24:03] deleted in Luminary 34 [08:24:36] heheh [08:24:41] Sundance is such a fun program [08:24:57] anyways, I finished everything in bank 32 except for P10/P11 today [08:25:10] tomorrow is bank 33, which is mostly servicer stuff [08:25:12] nice work [08:25:15] thanks :D [08:25:29] why do I think servicer will also be interesting [08:25:45] P70 and P71 were extremely different [08:26:00] so, who knows what we will find lol [08:26:22] yeah haha [08:26:35] ROSENCRANTZ (R11) still exists as its own routine in Sundance which was need to discover [08:27:22] anyways, it's past bedtime [08:27:23] goodnight! [08:27:30] night! [17:12:15] Hi folks! [17:15:32] Indy, you were absolutely right! It was an initialization bug in the agcio (I misunderstood how to use scanf on zero-padded values). I uploaded the corrected version, if by chance you could shoot a test on it, I'd be grateful. [17:15:55] morning! [17:15:57] nice find :D [17:17:21] hey ggalfi [17:17:28] will do [17:17:34] and hey Mike [17:18:28] Hey Mike, I was thinking the CDU-problem you came up with last time (what happens due to ATCA-LGC voltage change, and what about phase shift eliminated by interogation pulses) [17:20:23] I haven't done any simulation on it, just thinking. And seem to me it depends on the initial angles on whether it settles at a single (albeit erroneous) value or enters into a limit cycle state. [17:21:28] yep, it definitely depends on the angles :) [17:21:40] the exact moment that you switch out of LGC is very important, haha [17:22:31] I mean it depends on the physical angles of the device (shaft and trunion) [17:22:49] Not only the phase shift between LGC and ATCA [17:22:56] yeah, that's what I meant [17:23:23] up until the point you switch out the antenna will be moving [17:25:13] indy91 and I were debating a while ago whether the antenna continues to be inertially stabilized in SLEW mode [17:25:24] he says there's no way but we haven't found 100% proof yet lol [17:26:27] ggalfi, clock issue is fixed [17:26:52] Indy: Wov, great, thanks! [17:28:57] Mike: As far as I remember, I've seen some checklist which implictley suggested that there is some sort of stabilization in SLEW mode. [17:29:19] I guess it was the RR Gyro test itself [17:29:58] But I cannot remember where I've seen it. [17:34:49] But I believe, even if the angles are "frozen" you can be unlucky with that and make CDU to oscillate. [17:35:06] yes definitely [17:35:15] but I have never gotten it to oscillate "correctly" yet [17:37:46] "Examination of some printout of this list showed total excursions of about 13 deg. almost entirely at 6.4 KC. It is estimated that the reversals which were at slow rate resulted in an average 15% pulse loss compared to a continuous 6.4 KC slewing. However, it is felt that this is representative of the condition in the vehicle. Converting the central processor time loss from both CDU channels this is 13% instead of 15%." [17:38:20] so far my model has only ever reall oscillated back and forth up to 6 counts or so, and it stays at full high rate while doing so [17:39:13] and the full 6.4 KC is definitely way to much load [17:41:25] I think the if the sin(angle- readcounterB15-B13) is small then the reference signal (which is synchronous with the interrogation pulses) can dominate and causes the read counter oscillate till B12-B9 goes a full cycle. [17:43:38] My simulation is way to simple, it does not take into account that in certain cases the sin(angle- ...) part is large enough to shift the phase of the Schmitt-Trigger in the coarse system to avoid the interrogation pulse. [17:47:31] I still don't think the RR is inertially fixed in slew mode [17:57:54] LM_Systems_Handbook_060269.pdf - there is a drawing on the with the full GNC and it shows that every shaft and trunnion driving signal goes through the Gyro even if the Slew mode is selected. However it is a big picture, so I don't know how this document is reliable when it comes to fine subtleties. [18:01:08] would that also apply when the LGC is driving the RR? [18:01:34] in that case, if the LM had an attitude rate, the LGC would fight against the gyro [18:03:20] that whole system with the gyros is also responsible for driving the RR at all though, in any mode [18:03:43] so it sometimes is confusing when the gyros are mentioned [18:06:01] I think that the fighting problem is not a problem when you know the transfer function of the other system you want to fight with :) [18:07:31] The LGC produced angular speed commands and I guess the engineers have taken into account some sort of overreaction of the Gyro [18:12:59] maybe that's also why it is called "continuous designate". If the RR was only moving when it's doing auto tracking then the LGC could just drive the RR to the desired position and stop doing anything [18:16:28] but I am not convinced yet [18:17:28] ok, during initial RR checkout [18:17:37] RNDZ RADAR sel - SLEW [18:17:46] and then [18:17:58] the RR AC circuit breaker is closed [18:18:00] wait 30 seconds [18:18:09] and then the main RR breaker is closed [18:18:14] the reason for this [18:18:23] for waiting [18:18:45] "Prevents: (1) Probable high-rate driving of antenna into stops and (2) probable unpredictable preformance during gyro spin-up" [18:20:55] Is it in the Activation Checklist? [18:33:52] that's from the AOH Volume 2 [18:49:32] the servicer is interesting alright :D [18:56:19] haha [18:56:22] I got something right with the timing in the LVDC [18:56:44] just had to set myself the goal of implementing nothing else and go for the least invasive approach [18:56:55] still testing things [18:57:08] oh nice! [18:59:10] I call the LVDC timestep 100 time per second [18:59:23] the major loop takes 1.7 seconds to run, as before [18:59:34] minor loop 25 times per second during boost, 10 times in orbit [18:59:56] so without reorganizing some stuff is now run 100 times per second [19:00:05] but not much and I can fix that over time [19:03:45] so I have a counter for the minor loop [19:03:58] counts to 4 or 10 before the minor loop gets run [19:59:56] about 25% of the way through bank 33 [20:00:03] servicer has been largely rewritten for Luminary [20:00:15] the basic structure is the same but the code is quite different [20:02:00] not surprising [20:44:53] night! [21:14:32] Anyone here is familiar with Orbit Hangar? I'd like to make my Tranq Base scenery public. I'm able to create the addon but when I upload the files (two files, one for texture, one for elev), it shows 0 bytes for both. [21:20:13] hmm, that'w weird [21:20:24] I've never used it [21:30:33] I'm open to any idea where to upload it. Although it adds a lot to the user experience of the manual flying phase of the LM, technically it is independent from NASSP, so I don't think it'd be desirable to bloat up that with my meter-resolution textures. And there could be users who don't want to mess with NASSP (e.g. AMSO fans) but want to land [21:30:34] beside Little West Crater. So I'm now looking for an appropriate place for it, and Orbit Hangar looked like a natural choice. [21:49:56] yeah that seems like the ideal spot [21:50:02] I'm not sure what the other options are... [12:00:36] .in 6h scenery spot [16:13:37] morning! [16:15:19] hey Mike [16:16:13] got about 70% of the way through bank 33 last night [16:16:20] I think the rest is mostly landing radar related [16:17:20] LR stuff can't be more buggy than early Luminary [16:18:59] your Luminary 69R2 reconstruction is getting a bit of coverage, saw an article about it [16:19:13] wait till they find out it's your least impressive reconstruction :D [16:25:50] hahaha [16:29:47] hi mike [16:30:06] Hey guys [16:31:22] hey [16:34:30] question, what exactly is a 511 program alarm? [16:37:36] it happens when the software believes that the landing radar is in the wrong position [16:37:49] Luminary 99 and earlier were not very good at it [16:38:04] Astronaut, crank that silly thing round! [16:38:49] indy91: yeah I don't even know where we would begin making a video about Luminary 178 [16:39:28] n7275, when did you get that alarm? [16:39:57] thewonderidiot, reconstruction of 178 was very, very impressive [16:40:23] but I guess it was a lot like Luminary 69R2 [16:40:29] just... more of it :D [16:40:57] pushing things around until Antares did the landing [16:41:20] hahaha yeah [16:41:36] much, much more of it [16:42:08] thewonderidiot, during landing Apollo 11. occasionally orbiter will freeze briefly and after which the LM makes some hasty attitude and throttle adjustments [16:42:26] makes sense that its throwing the radar off too [16:42:58] hmm [16:43:23] but even with that it shouldn't throw the LR into the wrong position :D [16:43:46] is that in the AGCIO branch of ggalfi? Or do you get those issues in general? [16:46:10] what I have, a little bit, and I think it's only in the LM is also occasional little freezes [16:46:17] when the RCS is firing for example [16:47:04] could even be an Orbiter Sound issue [16:50:35] no that was with the standard. I can't make it more that 80sec or so into the burn on the agcio branch [16:51:23] it may also have been my fancy keyboard maneuvering [16:57:24] but 511 alarm is still weird [16:57:46] hmm [16:58:10] I wonder what the issue is with your performance though [16:58:15] NASSP is quite CPU heavy I think [16:58:18] might be that [16:58:47] I have a feeling it is [16:59:14] You can heat your house with NASSP's CPU usage. [16:59:54] And the main thing we can do about that is the panels [17:00:00] Yes [17:00:02] I was the only one having issues with the agcio branch right? [17:00:22] What FPS do you get? [17:00:22] I haven't tried a full landing, but with the latest fix it works pretty well for me [17:00:41] I can see the system cycles having some difficulty if they run too slow. [17:00:42] I did a full landing before, in our old scenario [17:01:35] about 25fps or so [17:02:00] Should still be ok then [17:03:00] but with occasional freezes that feel like they're 250 to 500ish milliseconds [17:03:07] ok, but not good [17:03:15] Yeah, freezes are very not good [17:03:36] yeah, I really need to investigate the freezes. I think everyone gets them, you just have them much worse than I ever get them [17:03:52] and it only happens with a powered up LM [17:04:48] I have only ever noticed freezes when switching panels in the CM. But it's been a while though, nor have I actually gotten an LM powered up and in undocked flight. [17:05:52] yeah, there is way too much code that is run when you switch panels [17:05:59] that could probably also be improved a lot [17:06:36] Once the VC is fully working we can retire all the 2D panels. [17:06:38] but the LM freezes are different [17:06:39] definitely looking forward to that day [17:07:09] I don't see a reason to maintain two cockpits when the API for the 2D cockpit is obsolete anyway. [17:07:17] theres a thread from 2009 I think on MSC forums talking about the pannel switching performance issues [17:39:16] I have a bitset with 26 bits [17:39:32] I want to save and load it from a scenario using our function for integers [17:40:20] I guess I have to convert it to int before being saved [17:40:35] Take a look at how AGCState is saved. [17:40:36] or else the line saved in the scenario might overflow the sscanf? [17:40:57] You can construct a bitfield the size of an int. [17:41:01] And then save that. [17:41:15] https://www.tutorialspoint.com/cprogramming/c_bit_fields.htm [17:41:24] bitset [17:41:32] but I could use a bitfield I guess [17:42:08] Oh those [17:42:32] http://www.cplusplus.com/reference/bitset/bitset/ [17:43:29] for AGCState, it just calls oapiWriteScenario_int with the unsigned long as the input [17:43:34] so that should be fine [17:44:10] what gets saved in the scenario then is signed, so that can have a minus [17:45:54] then I get an int with papiReadScenario_int [17:46:40] so the last questionable thing is ModeCode25 = tmp; [17:46:44] ModeCode25 being the bitset [17:46:47] tmp being an int [17:48:21] Saving it shouldn't change the sign. [17:48:48] It gets cast from unsigned to signed when saving and the other way around when loading. So it's not changed. [17:51:06] Okay, so looking at the reference you can just create the bitset with any size you want, provided orbiter can save it. So sizeof int would work or whatever amount of bits you need. [17:51:25] Then just set everything like an array and do bitset.to_ulong and save that with oapi. [17:52:21] yeah, that's what I do [17:52:51] so the line in the scenario is definitely an int [17:53:40] but I guess reading also works without issues [17:53:44] AGCState does [17:53:45] sscanf (line+5, "%d", &state.word); [17:53:52] state.word is unsigned long [17:54:03] and the line in the scenario can have a minus [17:54:40] just not sure yet if I can simply do "ModeCode25 = tmp;" [17:55:11] after if (papiReadScenario_int(line, "LVDC_ModeCode25", tmp)) [17:55:34] The minus is whatever the sign bit is set as. When it's loaded in that is interpreted as an unsigned integer. [17:56:18] The most significant bit indicated positive or negative in a signed integer but for an unsigned it's just another data bit. [17:56:48] right [17:59:07] still not sure though if ModeCode25 = tmp; is save... [17:59:11] safe* [17:59:31] That %d in sscanf should be changed to %ld if you need more bits though. [17:59:57] I need 26 [18:00:09] Should be fine. You have 32 [18:00:11] yeah [18:00:34] Unless tmp is a pointer you should be fine. [18:00:47] Oh right. [18:00:49] Thanks Guenter. [18:03:39] ggalfi was on last night wondering what to do with his moon textures. [18:04:22] He suggested Orbiter Hangar. I'm not sure if including it in NASSP is a good option. [18:04:34] Orbithangar should be fine [18:05:19] On one hand the textures aren't a depdency. On the other hand I don't think it's desirable to have NASSP 'upgrade' packs thrown around for lack of a better word. [18:05:55] we don't have special Moon textures anymore [18:06:09] so it's more of a general Tranquility Base upgrade, usable in NASSP [18:08:22] Okay, then I think it should be released as its own thing not referencing NASSP. We can list it as a recommendation like with the high res textures but it shouldn't be listed as "High Res Tranquility Base textures for NASSP". [18:10:41] yeah, there is probably nothing stopping it from also being nice for AMSO [18:11:16] Do his textures use any NASSP files? [18:11:56] not sure [18:12:04] I'm sure he can tell us [19:17:51] https://github.com/orbiternassp/NASSP/pull/537/files/aed77178fbc5226b05f6e593227d569222755ff4..249e862682633d9076497bca0bf44528ef2f040f [19:18:00] Isn't strnicmp() a deprecated function? [19:46:42] I think so [20:01:11] Do we have compiler warnings turned on for that? [20:01:25] I'd guess not because I think that file is full of them. [20:03:25] I wouldn't know [20:04:10] I'll check when I have some time. [20:04:20] .in 8d check strnicmp [20:09:19] great [20:49:41] night! [11:50:53] morning [14:15:05] hi folks [15:16:41] good afternoon [15:51:58] hi all [15:56:25] hey [16:00:43] Just got back from Colorado, finally readjusting to humidity here in VA lol [16:09:22] hey Ryan, you weren't here for a bit I think [16:12:51] I'm working a bit on the LVDC right now [16:13:20] Mike is trying to piece together Sundance, the Apollo 9 LM software [16:13:32] I'm helping a bit, what little I can do for that :D [16:16:35] morning! [16:16:46] I finished bank 32 and started P10/P11 last night :D [16:17:25] oh man [16:17:34] let me guess [16:17:37] you first input a time [16:18:07] there are SO MANY displays at the beginning [16:19:12] hahaha [16:19:14] I can imagine why [16:19:35] V06N33 -> V06N81 -> V06N91 -> V06N92 -> V06N56 -> V06N37 -> V06N94 [16:19:41] and then it finally starts calculating [16:19:42] lol [16:20:21] N33 will be the initial guess for the liftoff time [16:20:49] N81??? [16:20:59] N91 makes sense [16:21:07] N92 makes sense [16:21:20] N56 also [16:21:31] N37 as well [16:21:39] and N94 as well [16:21:40] ... let me make sure I calculated the 81 correctly [16:22:02] N81 would be a DV input [16:22:13] at least according to the Systems Handbook [16:22:21] yes, it's definitely N81 [16:22:24] which has been wrong in some cases [16:22:50] also there's a branch after the N81 that I don't understand at all [16:23:04] that's probably where it decides between short and concentric profile [16:23:13] maybe you input that in N81 somehow [16:23:20] it's looking at address 0140 [16:23:28] which is just a temporary used by some places [16:23:31] as far as I can tell [16:24:41] only thing I can think is MIXBR or DSPMMTEM [16:24:44] but both are weird [16:25:22] ah I'm dumb, it will just set some flag when you start P10 or P11 [16:25:33] that of course decides which one it will run [16:25:36] yeah [16:25:50] N81 is definitely used as a DV in Sundance [16:26:12] oh here [16:26:13] in P34 for example [16:26:14] this might help [16:26:26] oh of course [16:26:29] my display chain was slightly worse [16:26:32] er [16:26:32] wrong [16:26:40] it's the insertion velocity [16:27:26] in Luminary that is N76 [16:27:38] but that will come after N33 [16:27:39] after N81, you either get the N91 and N92 displays, or you get the N56, N37, and N94 displays [16:27:44] so I think all the inputs make sense to me [16:27:51] yeah [16:27:54] that will be P10 vs P11 [16:27:58] weeeeiird [16:28:05] how does look at address 0140 tell you that... [16:28:29] I wonder if they're using DSPMMTEM to figure out if the last digit of the MM display is a 0 [16:28:32] in which case [16:28:33] gross [16:28:35] lol [16:28:42] hahaha [16:28:45] that could be it [16:29:00] which displays would correspond to which program? [16:29:31] N91 and N92 for the short profile [16:29:50] P11 [16:30:05] that has to be it [16:30:22] because it does the N91 and N92 displays if address 0140 is not zero [16:31:23] interesting solution [16:31:37] it's memory efficient, you don't need to store that P10 vs. P11 flag anywhere else :D [16:31:49] lol [16:31:55] the entry looks like this [16:32:17] 32,2000: 05575 0 P10 TC DOWNFLAG [16:32:17] 32,2001: 00140 1 ADRES 2PHASFLG ; FIXME: Make up different name for this! [16:32:18] 32,2002: 02005 0 TC P10/P11 [16:32:19] 32,2003: 05563 1 P11 TC UPFLAG [16:32:19] 32,2004: 00140 1 ADRES 2PHASFLG [16:32:20] 32,2005: 00006 1 P10/P11 EXTEND [16:32:20] 32,2006: 31423 0 DCA TIG(AS) [16:32:21] 32,2007: 53425 1 DXCH TIG [16:32:41] the only difference between the two is one sets the flag and one clears it [16:32:49] ah [16:32:52] but I guess it look less instructions to look at DSPMMTEM at that point [16:32:59] instead of using their flag [16:33:00] lol [16:33:10] oh they have a flag but don't use it [16:33:13] that's bad :D [16:33:20] hehe yeah [16:33:31] well I can definitely work out good inputs for P11, it's not exactly the inputs you would have in e.g. the RTCC [16:33:42] but I think trajectory wise you can get the same thing [16:33:46] with the right inputs [16:33:51] speaking of inputs [16:34:02] N56 is easy [16:34:11] one thing that would be extremely helpful is if you could work out anything that may have been padloaded except for TIG(AS) [16:34:14] N37 is needed anyway [16:34:35] so anything that needed, but not one of the input nouns? [16:34:39] that is* [16:35:05] also that -- if other things would have been expected to be set by landings [16:35:11] or other programs [16:35:31] lunar surface flag maybe if there is such a thing [16:35:43] it references several erasables that I don't *think* were referenced anywhere else in Sundance [16:35:47] but what it would need is: CSM state vector, landing site vector [16:38:03] hmm [16:39:28] N94 has "CSI altitude" [16:39:37] that's not really like in the GSOP [16:39:56] if CSI altitude is an input P10 would have to somehow calculate the insertion velocity [16:40:22] what seems to not be part of the noun inputs is the ascent parameters [16:40:42] time from launch to insertion, travel angle, and height of insertion [16:40:47] that's probably padloaded [16:41:45] excellent [16:42:17] there is only one register for time [16:42:18] I think I'm going to continue to blindly disassemble it, and then at the end begin back out the interpretive equations [16:42:31] like R2 of N94 [16:42:39] I guess you input that in XXX.XX hours or so [16:42:39] I have a feeling we are both going to be better at reading interpreter code at the end of this :P [16:42:46] haha, yeah [16:43:42] I definitely want to reverse engineer what it does [16:43:57] seems to be a little bit different from that GSOP [16:44:09] not too much [16:44:11] but a bit [16:44:45] unfortunately that early GSOP doesn't have a section yet for erasable and fixed memory [16:44:56] so it wasn't decided yet what is user input, padload or fixed [16:45:07] haha yeah [16:45:18] there's also plenty of constants that it is referencing [16:45:27] I'm sure we can figure those out [16:45:33] with to-be-determined scaling :P [16:46:04] yeah, scaling is always "fun" [16:46:45] would be quite exciting if Sundance really has a bunch of improvements over the GSOP [16:47:34] yeah it would :D [16:47:49] based on progress last night I think I should probably be able to finish the first pass disassembly tonight [16:50:07] ah great, then I can try and read it a bit [16:51:18] actually, I already have a big chunk of interpretive disassembled [16:51:25] let me push it so you can see what it's looking like [16:51:59] nice, thanks [16:53:39] https://github.com/thewonderidiot/sundance/blob/master/b5_292.disagc#L2363 [16:54:35] time to learn the instruction set... [16:54:39] :D [16:57:48] oh nice, the interpreter has a vector projection feature [16:58:00] yeah [16:58:03] a very powerful instruction lol [16:58:27] definitely used here [16:58:31] yep [17:00:04] so when you input something in a noun, like N81 [17:00:27] that goes to the erasable location specified for the noun? [17:00:32] yes [17:00:54] I'd like to figure out where the N81 input get used again [17:01:11] because at the start of P10/P11 it just is the chain of nouns, not much other processing at first [17:01:16] those are encoded in the IDADDTAB [17:01:32] which bank is it? [17:01:37] https://github.com/thewonderidiot/sundance/blob/master/b6_306.disagc#L5172 [17:01:48] ah thanks [17:01:54] it is... less helpful without comments [17:02:37] so DELVLVC [17:03:18] ah, but I guess you haven't done that part [17:03:59] hmm [17:06:45] I have a lot to learn... [17:07:59] lol [17:08:03] but I think I understand the first part. one branch for P10, one for P11 [17:08:13] comes together again for 32,2042 [17:08:21] where the fun part begins, "INTPRET" [17:08:31] yep :) [17:09:11] first thing it does is TIG(AS) + UE7,1743 [17:11:06] I see E7,1743 in the nouns [17:11:21] yeah, middle register of both N92 and N94 -- I think [17:12:11] time from launch to CSI (P10) or TPI (P11) [17:12:15] TPF* [17:12:32] I guess N92 has time in R2, angle in R3, R1 blank [17:12:39] or as the noun table says [17:12:40] "7" [17:14:05] I guess it's setting up CSMPREC [17:14:37] yeah [17:14:48] it's putting that into TDEC1, which is the time CSMPREC integrates to [17:15:29] already a bit different to the GSOP [17:15:37] haha oh boy [17:16:41] but if it needs to do anything with the CSI altitude then CSI time makes sense for P10 [17:18:00] so DLOAD DAD takes the values of the next two lines and stores it in MPAC [17:18:12] and then STORE UE7,1673 stores that in that address [17:18:25] close, those are two different instructions [17:18:32] the DLOAD loads TIG(AS) into MPAC [17:18:50] and then the DAD adds UE7,1743 to it [17:18:57] ah [17:19:00] weird syntax [17:19:03] DLOAD and DAD first [17:19:05] and then other stuff [17:19:06] polish notation :D [17:19:17] as they called it, haha [17:19:29] right [17:19:45] but yeah, it's space efficient because they can use 7 bits for both opcodes in the first word, and then all 15 bits for the argument to each [17:20:01] true [17:25:30] SSP is float a = (float)somedouble :D [17:26:15] but I have to keep track what is in MPAC at all times... [17:31:34] MPAC can have scalar and vectors? [17:31:52] yes [17:33:35] yeah [17:33:44] has SSP two arguments or one? [17:34:10] two, I believe [17:34:11] if it's two then the Virtual AGC website has it wrong :P [17:34:31] it's load a constant into an address, right? [17:34:36] and specifies both the address and the constant [17:34:49] yeah [17:34:50] yeah, it says location X to location Y [17:34:59] I was just confused by the "A" instead of "A,A" [17:35:06] small error [17:35:14] I guess [17:36:04] so SSP UE7,1662 loads 0 as a single precision value in UE7,1662 [17:36:11] "SSP UE7,1662, 0" [17:37:08] right, yes [17:37:21] VATT1 must be some vector [17:37:56] orbital integration result maybe [17:42:41] I can already see the advantages of the interpreter [17:42:49] you can get a lot done in not a lot of lines of code [17:45:38] U32,2563 is probably the radius of the Moon or so [17:47:54] VATT1 is integration result, yeah [17:47:55] one sec [17:47:59] yeah, octal 324 is decimal 212 [17:48:17] multiplied by 2^13 it is 1,736,704 [17:48:24] because of the missing code I've been reading a lot about integration lol [17:48:52] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/INTEGRATION_INITIALIZATION.agc#L162 [17:49:15] also nice find! [17:49:20] what's the difference between VATT and VATT1 [17:49:39] looks like scaling? [17:49:47] ah [17:49:51] such a small number (0324) gives quite terrible precision [17:49:59] oh, is it supposed to be double precision? [17:50:22] interpreter rarely does anything single precision [17:50:42] that's a yes [17:50:48] yeah 32,2563 is double precision [17:50:49] 1,738,090 [17:50:54] that's why I put a "2DEC" there :P [17:50:56] right [17:51:13] mean radius of the moon right there [17:51:17] have to keep that in mind [17:51:23] mean radius, it's not using the RLS radius [17:52:04] it calculates the TPI radius from TPI altitude and lunar radius there [17:52:23] excellent [17:52:52] got a suggested name? feel free to come up with and tell me names for anything that I have just called U
[17:53:04] until we have a document that gives us real names we can call them whatever we want :) [17:53:41] Luminary has that constant [17:53:46] exactly that one [17:54:01] ah of course [17:54:05] needed for orbital integration [17:54:24] different scaling? I'm not seeing the octals [17:54:38] 002519,000301: 04,2002 00065 01265 504RM 2DEC 1738090 B-29 # METERS B-29 (EQUATORIAL MOON RADIUS) [17:54:56] yeah scaling is different [17:55:07] aha :D [17:55:19] have to check what it uses for orbital integration [17:56:11] even the Sundance GSOP has that value haha [17:56:51] if it doesn't use the same constant (same address) then we need a different name [17:57:14] yeah, we need a different name [17:57:32] 504RM also exists in Sundance [17:57:41] 13,2560 [17:58:52] that will have the same scaling as Luminary I guess [17:59:00] but probably the same number [17:59:00] yeah [17:59:08] 1738090 meters [17:59:14] it's exactly the same as Luminary [17:59:21] just not defined in CONTROLLED CONSTANTS :P [17:59:22] good [17:59:26] we need that for P10/P11 :D [17:59:35] wait do we? [17:59:43] well, orbital integration in lunar [17:59:43] well for integration yeah [17:59:44] lol [17:59:44] orbit [17:59:51] we need it for many things :P [18:00:00] only that one though, most of the calculations are conic [18:00:29] but yeah, I doubt that will be an issue, integration in lunar orbit [18:00:59] not sure about the name, something with "RM" [18:02:35] P10RM? :P [18:02:45] or RMB27 or something [18:03:21] I like P10RM [18:04:17] it doesn't do much with RATT1 and VATT1 at first [18:04:28] just loads them into MPAC and saves them elsewhere [18:04:39] scared they get overwritten by something else? :D [18:04:58] they're just in the pushlist [18:05:07] so getting overwritten is very possible [18:05:23] they do it efficiently though [18:05:36] in between the TPI radius code [18:05:54] confused me at first [18:06:46] but then it uses VATT1 again [18:06:56] despite it having stored it somewhere else... [18:08:22] probably just saved it for later, so the same value exists in two places and it doesn't matter which they use [18:08:29] yeah [18:08:32] ah, more constants [18:09:30] "PUSH [18:09:30] Push. Pushes the contents of the MPAC onto the stack." [18:09:35] what does that mean? [18:11:26] that pushes the item onto the pushdown list [18:12:06] which can be referenced by low numbers, like 0D, 2D, VATT1, etc. [18:12:34] and also can be used for implicit arguments to instructions [18:12:35] like [18:12:38] let me find a good example [18:13:49] oh here [18:13:50] http://www.ibiblio.org/apollo/Documents/SymbolicListingInformation.pdf [18:13:54] symbolic listing information [18:14:00] page 232 [18:14:04] could be helpful with examples [18:14:32] in the first example, PDDL (equivalent to PUSH and DLOAD combined) pushes a value onto the stack [18:14:40] and then there's a DAD without any arguments [18:14:57] and that causes it to remove that value from the stack [18:15:02] and use that as its argument [18:17:23] ok, a literal stack, got it [18:17:41] have to keep track of what is in MPAC and the stack then :D [18:17:45] yep [18:18:02] things get tricky with heavy stack use [18:19:17] ah I think it immediately uses it [18:19:24] a STODL, but only one argument [18:21:43] which address? [18:21:57] 32,2072 [18:22:30] PUSH DAD [18:22:33] TIG(AS) [18:22:37] STODL UE7,1373 [18:22:43] yep [18:23:18] does that store MPAC to UE7,1373 [18:23:30] and the reloads the value it had saved on the stack back to MPAC? [18:23:33] then* [18:27:09] yeah so, the goal there is to put MPAC + TIG(AS) into UE7,1373 [18:27:21] but they don't want to lose what was in MPAC [18:27:30] so they save it in the pushdown list for that addition [18:28:33] almost makes sense [18:28:42] but all they had in MPAC was U32,2557 [18:28:51] maybe they just don't want to load it from fixed memory twice? [18:29:42] BDSU TIG(AS) is the same as MPAC = TIG(AS) - MPAC? [18:29:52] heh, yeah I guess [18:29:54] sorry for so many questions, I'll learn it over time :) [18:29:57] and I think so? [18:32:27] yeah [18:37:34] U32,2557 is half an hour [18:37:39] 180000 cs [18:38:31] nice! :D [18:52:12] STODL TTOGO, ZEROVECS. STORE UE7,1755 [18:52:33] Does that really load the x-component of the zero vector into MPAC and then also stores that 0 in UE7,1755? [18:53:36] oh no, lots of pushes upcoming... [18:53:46] yes, I believe so [18:53:52] and the disassembly looks correct from the octals [18:54:19] weird [18:54:33] but it's possible I'm wrong, if you think it should be doing something else [18:55:38] what do you mean, what could be wrong? Wrong disassbly? [18:55:41] yeah [18:55:47] again I think it looks right [18:55:51] I just find it weird that it does all that effort to put a 0 in some spots [18:55:56] not necessarily wrong [18:56:25] but with interpretive if you end up thinking an argument is an instruction or vice versa it all goes to hell quickly :D [18:56:44] haha yeah, I can imagine that now [18:57:29] the only thing I would doubt that it's really doing that with ZEROVECS, a zero vector. But if that's correct then the whole thing is correct [18:57:41] so [18:57:50] 32,2076: 17427 0 STODL TTOGO [18:57:56] the leading 1 makes it a STODL [18:58:04] if it were STOVL, it would be 27427 [19:02:01] yeah I'm pretty confident that is correct [19:02:28] I have no reason to doubt it [19:06:34] STORE RDOT ; FIXME: label? [19:06:57] it stores the landing site vector in BRCS coordinates at the predicted time of liftoff [19:07:13] if you want to change the label [19:07:36] so it's not RDOT? lol [19:07:44] I didn't really think it was but couldn't immediately disprove it [19:07:47] not an RDOT, no [19:07:50] cool [19:08:19] do you have an 8-character name for it? :P [19:08:45] GSOP does the opposite operation lol [19:08:52] RLSsomething? [19:08:54] haha [19:08:55] but the GSOP is old [19:09:05] definitely not how that kind of operation would normally work [19:09:09] nice [19:09:25] so these are even more interesting than they would be if they were a direct GSOP implementation :D [19:09:27] RLSBRCS [19:09:32] that works! [19:09:52] I'm sure Luminary does something similar somewhere and has a better name [19:10:01] or does it [19:10:07] P12 would convert it to guidance coordinates only [19:10:12] maybe P22 [19:10:17] RLSBRCS will do :D [19:12:57] I mean, there are lots of overlays, right? [19:13:03] So RDOT might still be correct [19:13:06] for e.g. P12 [19:13:18] just in this context it is not an RDOT [19:14:02] oh yes, there are multiple overlays [19:14:28] there are some locations that had other names but I knew for sure they had a different name for P10, so I called those UE7,xxxx [19:14:31] but some of them [19:14:34] like RDOT and TTOGO [19:14:42] I guessed that maybe they were the same [19:14:59] all of the ones I wasn't positive about I put FIXME: label? [19:15:13] right [19:15:52] what is stored in TTOGO is a time, but not time-to-go. But I am not 100% on what it really is yet [19:15:52] so I have nothing better [19:16:06] it's that half an hour thing, not like that in the GSOP [19:16:09] but I have some ideas [19:17:07] okay, so that's probably wrong too :D [19:18:22] ah damn, already made that argument vs. instruction error [19:18:45] this list of interpreter instructions isn't good enough [19:19:00] on the Virtual AGC website [19:19:25] like, I don't know what the cross product calculation uses as inputs [19:21:32] symbolic listing information is probably a better reference [19:22:33] cross product being VXV? [19:22:43] yes [19:22:46] pdf page 186 [19:22:50] yes [19:22:54] I thought UNIT was a unit vector [19:22:55] haha [19:23:03] but it's the operation of doing a unit vector [19:23:16] not a constant [1 0 0] or so :D [19:23:19] oh yeah [19:23:25] it forms a half unit vector right? [19:23:41] out of what is in MPAC [19:24:15] I think so [19:24:47] now it makes sense [19:24:52] RATT1 x VATT1 [19:24:58] not UNIT x VATT1 [19:25:35] calculates the orbital plane unit vector [19:27:49] is there a difference between VPROJ and VPROJ*? [19:39:19] VPROJ* would be indexed [19:39:32] so its argument would be