[16:15:54] NASSP Logging has been started by indy91 [16:15:56] hey [19:15:08] good afternoon [19:50:01] hey hey [19:50:04] how's it going? [00:02:03] oh, not too bad. still quite busy [15:39:55] hey [15:59:37] morning! [16:03:20] what's up? [16:04:04] hopefully finishing up the layout for the AGC board for the CDU setup today [16:04:16] and also should be getting in a new 16:1 gearbox to try with the resolvers [16:04:30] and you? [16:05:19] ah fun [16:05:49] I'm working with wxWidgets for a GUI right now. I like it, let's me do things in a very C++ way, but removes all the overhead and problems I have had with Microsoft's own tool [16:06:23] converting the inputs for the launch window processor right now from a text file to GUI [16:06:29] nice :D [17:59:26] https://i.imgur.com/u7qFuPe.png [18:00:35] this launch window processor version is from the 1979 Flight Design System documents. Kind of meant as a general analysis tool and not specifically to supply data to the Shuttle computer or so. [18:00:54] So it's not really 100% helpful to supply data for NASSP or SSV directly [18:01:29] I might have to port some extra code from the RTCC and FDO MFDs [18:01:50] but I am happy with the way GUIs are designed with wxWidgets, I will proceed this way [18:01:55] looking good! [18:04:39] I guess drawing the output on pop up windows is better than text files, I'll try to figure that out next [18:43:25] cya! [11:53:06] hey Nik [11:56:30] hello hello [11:57:31] does wxWidgets need any kind of runtime library on the user side? [11:58:22] I haven't looked into that yet :D [11:58:52] I guess I will have to once this becomes release ready haha [12:05:54] Simple popup window for output displays: https://i.imgur.com/SBcHtaA.png [12:21:41] oooo nice! [12:47:34] can it to plots natively? [12:49:40] I think there is limited support for it, but to do it properly I think I would need to install this: https://wxmathplot.sourceforge.io/ [12:50:13] The OMP had a plotting capability, I sure want that as well [12:53:59] https://i.imgur.com/l9z29PZ.png [12:54:03] getting plots like this [12:55:21] The next thing I am interested in, the maneuver constraints table for the OMP basically has a CSV file format. If that could easily be edited inside the application, that would be really nice [15:43:07] morning! [16:21:19] hey Mike [19:02:25] thewonderidiot, you got us the Skylab TLEs a while ago, right? [19:02:49] Before that I had build the Skylab state vector for us by hand, I'm trying the TLE now. So far the phase angle doesn't make sense... [19:09:47] uhh [19:09:53] time issue :D [19:11:07] oh I previously copied a state vector from just before liftoff out of a scenario [19:11:23] but now I went back to the T-4h one, but didn't change the MJD of it [19:12:03] much nicer solution of course lol [19:20:37] haha got it all sorted? [19:21:40] yep [19:22:05] essentially a copy&paste error on my part [19:24:12] this TLE would work well for us, I just have to regenerate the LVDC targeting [19:26:21] awesome :D [19:26:29] or add the Saturn IB specific targeting to this new tool first haha [19:38:55] oh yeah, the targeted inclination and descending node angle agree to 0.02° to the flight evaluation report values now [19:39:42] inclination is 0.008° different, descending node probably slightly more due to the whole Orbiter timing system confusing [19:39:50] confusion* [19:40:11] very nice! [19:40:50] I'll give it a test run but this should be a pretty safe change [19:41:12] The main difference is the phase angle not being ideal for the actual Skylab 2 launch day [19:41:22] so instead of a 125 NM apogee as planned they had to use 190 [19:42:15] They also really wanted TV coverage on the US pass for rendezvous, to view the damage [19:42:44] Because of that they only considered a rendezvous on the 5th orbit instead of 5-8 orbits as planned [19:43:19] That also makes a difference for the insertion, they moved the ideal time for the 5th orbit rendezvous closer to the optimum liftoff time [19:44:17] plane vs. phase launch window aligning better for that specific profile [19:44:47] interesting effects of tweaking launch parameters [20:31:01] night! [17:26:30] morning! [17:33:40] Hey Mike [17:43:22] what's up? [17:44:43] I've added TLE support to this new planning tool. That should make things a lot easier with conversions and creating numbers for launch scenarios. [17:47:25] using the same dodgy coordinate system conversion as the Scenario Editor TLE tool, but, it seems to give decent results haha [17:47:30] oh very nice! [17:48:59] So I am not too far away now from being able to supply everything for e.g. a Saturn IB launch scenario to Skylab on a different launch day [17:49:17] Just select the Skylab TLE that is the closest and the tool would output LVDC targeting and a Skylab state vector for the scenario [17:50:15] and I want it to do the same for SSV [17:51:30] Sounds all pretty similar to the tool for planning Apollo missions to the Moon. I guess they have quite similar roles, just one for lunar missions with the Saturn V and this new one for Shuttle/Saturn IB ground-up rendezvous missions [17:52:14] that's super cool [17:52:34] And it's all meant to be the preflight planning. The RTCC MFD might still get more capabilities added because they could retarget in the RTCC on launch day [18:09:10] CDU project is waiting on a completed AGC board? [18:11:08] I ordered the board and all of the parts for it last night [18:11:24] "X=C [18:11:25] , Y=A [18:11:27] , Z=B" Is that from the order of the CDU modules in the tray? :D [18:11:30] also waiting on the right pinion gear for the resolver gearboxes [18:11:41] hah yeah [18:12:33] for the CDU, [18:12:34] A = inner gimbal [18:12:35] B = middle gimbal [18:12:36] C = outer gimbal [18:12:43] but for the AGC, [18:12:44] X = outer gimbal [18:12:45] Y = inner gimbal [18:12:45] Z = middle gimbal [18:14:36] someone liked PYR over RPY [18:15:23] so next board to design is probably the AAC filter & multivibrator [18:15:52] what is that needed for? [18:16:11] that's one of two modules that generate the precise 800Hz 28V reference for the CDU and resolvers [18:16:43] it generates a synchronized ~4V sine wave that the 800cps 1% amplifier module then creates 28V from [18:18:57] pretty strict requirements or easily achievable? [18:19:29] hmm what do you mean? [18:20:22] how precise this all needs to be for the CDU to be happy [18:20:43] probably 1%, going off the name of the module haha [18:20:57] the "AAC" part of the first module is automatic amplitude control [18:21:20] it actually closes the loop with the amplifier module and adjusts its own output such that the amplifier module will put out exactly 28V [18:24:42] I've been struggling with the 1% amplifier module. it's hard to find a transformer similar to its output transformer [18:24:53] I might use a more modern audio amplifier [18:30:15] so with the gearbox you will just rotate it by hand and that data gets fed to the read counter? That will be fun to see :D [18:30:33] How the CDU reacts [18:30:41] yep! [18:31:10] it will be much better than the current behavior of the read counter freaking out and oscillating whenever I turn one of the two resolvers haha [18:32:13] the might still be a bit of freaking out in some situations once everything works normal, that is expected :D [18:32:16] there* [18:32:28] hehehe [18:35:20] side project is mine is code reduction of the RTCC MFD display code. There is a lot to be gained, but it's difficult to automate. So a lot to do by hand in 10k lines of code... [18:35:24] of mine* [18:35:52] oof yeah that is a lot of code [18:36:41] I'm only even bothering with it because Intellisense has become slow for me in the RTCC MFD class and RTCC class :D [18:37:24] I definitely need to do something about the RTCC class, too. That's larger than the MFD by quite a bit. [18:38:24] I don't think a namespace is good enough, it needs to be one central class. But maybe I can split the RTCC up on subsystems, all having access to everything in the RTCC. [18:38:31] up in* [20:30:16] night! [15:09:00] morning! [15:11:16] hey [15:25:32] I'm adding saving/loading to this new tool. I've learned from the ATDP, I think I found a better system for save files. [15:25:58] oh yeah? what is your new system? [15:27:31] well wxWidgets helps. It write a .ini file in plain text and will automatically read from it, too, without me having to write extra code. ATDP saving is more efficient I guess, but it's binary. I guess what I have learned is: I don't have to reinvent the wheel :D [15:31:04] typically I dislike having to deal with external code and license and all that stuff, but with the GUI I need that anyway. Might as well use everything wxWidgets provides. [15:51:23] back in a few hours [19:52:44] .ini file sounds much nicer than a binary blob! [19:53:24] much easier to add or remove fields to existing save files if you make an update [19:57:06] Yeah, in the ATDP I just didn't want a line by line save/loading code like we have with NASSP scenarios, but if there is a library doing all the heavy lifting for you, it's better than binary [19:59:39] The next little feature is a tab handling state vectors. Just so that you can manage and edit them in the application and not in text files [20:00:16] That's of course a bit of a disadvantage of not running inside Orbiter where you can simply always pull the state vectors from the Orbiter API [20:01:28] My process right now could use some improvements. I have a bunch of files with TLEs and then for a specific launch day I need to manually find the TLE that is the closest and copy it over [20:01:33] I am sure that can be streamlined [20:01:50] without having to look on Wikipedia what day of the year June 5th is [20:10:12] lol yeah that definitely sounds streamline-able :D [20:16:05] that is more like the process we used to have with AGC padloads haha [20:16:13] very handcrafted [20:39:32] night! [16:36:26] morning! [16:37:18] hey Mike [16:39:05] what's up? [16:40:00] tinkering around with the ASTP rendezvous plan in my new tool [16:40:06] ASTP has some special challenges :D [16:41:09] oh yeah? [16:41:44] Soyuz does a maneuver in between Apollo maneuvers [16:42:13] a bit tricky for the rendezvous targeting [16:42:23] oh yeah that is a big difference from Skylab :D [16:43:02] also I've only added the capability for the target vessel to do maneuvers in this OMP version, Shuttle FDO MFD can't do that yet. I'm chasing a bug, but not sure yet if it's actually a bug. [16:53:08] not a targeting [16:53:09] bug [16:53:20] but an orbit that is circular and becomes less circular on its own [16:53:26] real or bug has to be seen :D [18:17:02] well I guess the orbit is not nice for a circularization [18:17:12] non-spherical gravity strikes again [18:23:09] an unrelenting villain :D [18:27:58] The circularization targeting reduces the altitude rate to 0 and adjusts the horizontal velocity to give the same altitude as right now in 180° of orbital travel [18:28:10] And with that you still get this wobble: https://i.imgur.com/kcsolyR.png [18:28:34] I guess this is a bit of a worse case, I have definitely seen more circular Earth orbits [18:28:38] worst* [18:29:34] depends where in the orbit (latitude) you do the circ burn [18:31:59] haha I've also seen worse "circular" orbits [18:38:42] The RTCC has a function that smoothes the predicted apogee and perigee with a simple J2 approximation, but it's also not faring too well with this orbit [18:39:33] The Shuttle computer has a really good calculation for this, too, for the displayed apogee and perigee. A bit more complex than the RTCC version [18:42:03] but even that display gives up if the predicted difference between apogee and perigee is less than 5 NM and just says the orbit is near circular :D [18:42:54] well it still shows the HA and HP, but not the predicted time to the next apsis [18:43:54] Better than conic at least lol: https://i.imgur.com/lW6lQZb.png [19:41:14] oh yeah haha [20:32:09] night! [16:12:08] morning! [16:27:05] good evening [16:40:59] what's up? [16:41:57] I've launched ASTP and now I am distracted by adding a mission specific system for tracking stations, specifically the ATS-6 relay satellite [16:42:19] I think I've had some ideas for this that can work [16:44:22] and you? [16:46:23] stalled on the CDU at the moment waiting for various shipments to arrive [16:46:50] so I might work on modern reimplementations of the PSA modules I need [16:47:16] but there are other thoughts bouncing around my head, like maybe I should just take a break and play video games this weekend instead lol [16:47:35] or _maybe_ launch Apollo 8 in NASSP [16:48:21] sound like good ideas haha [16:50:15] don't launch ASTP, that's kind of difficult still :P [16:53:23] hehehe [17:14:13] I would love it if you try Apollo 8! [17:49:45] haha and finally get some mission experience, after almost a decade [18:23:01] hey guys [18:23:19] hey Matt [18:23:31] I'm also encountering another issue :D [18:23:42] I don't think I introduced it [18:24:09] the current logic is that when there is a new ground station AOS then that one will become the transmitting station [18:24:42] I had AOS to the ATS-6 satellite over the Atlantic [18:24:46] then I had AOS Madrid [18:24:53] ouch [18:24:56] and I think it switched to that [18:24:58] but it gets worse :D [18:25:08] at LOS Madrid it did not switch back to the ATS-6 [18:25:28] I don't think our current logic can handle AOS/LOS within an AOS period of another station [18:25:36] yeah... it's just going to wait for the next one [18:26:04] Maybe it should be changed like this: It always stays with the current station, if it is available [18:26:21] at LOS it will pick the first(?) station it has a signal from [18:27:00] but this logic needs to be thought through, that it works right for low Earth orbit, TLC/TEC and lunar orbit [18:27:08] those cases are more important than a relay satellite... [18:27:51] with the current logic it doesn't properly reset itself either [18:28:16] in the scenario it saved that is has AOS to station 43, that is the ATS-6 [18:28:29] transmitting ground station is still 31, surely Madrid [18:28:35] if (AOSCount == 0) { [18:28:36] TransmittingGroundStation[Slot] = 0; [18:28:37] } [18:28:40] I think something needs to generate a list of stations to switch to [18:28:44] AOSCount is 1 because it has a signal to the ATS-6 [18:29:33] maybe there is some real MSFN logic to this [18:30:02] pretty sure that in my case Madrid and the ATS-6 were not far away from each other [18:30:16] So I don't think you would have them both transmitting at the same time haha [18:30:51] yeah, that wouldn't work very well [18:31:04] maybe we need a priority list? Could get complicated [18:31:49] well, we should be able to generate a list of all stations that can seethe spacecraft at ant time [18:32:11] if they had priorities it could pick the highest [18:32:30] or if some have the same priority, pick by closest [18:33:02] *"at any time" not "at ant time" [18:34:07] yeah, we have the AOS list [18:34:18] list of bools of which spacecraft currently are in AOS [18:34:44] I don't think that differentiates between S-Band and VHF, but, it could be added [18:35:38] "pick by closest" would be problematic again with the ATS-6 [18:35:50] because of the Madrid pass [18:37:00] yeah, I think a "priority" would be needed there [18:38:21] I would still like to learn more about how this worked in reality [18:38:30] I'm pretty sure I did I inplimented it they way I did so that stations would stay in AOS as long as possible...but it doesn't really have the intended effect [18:39:23] I do know that stations got a "SCM" or "station configuration message" teletyped to them by MSFN [18:40:09] and routing of traffic was manual *as far as I know* [18:42:32] according to the transcript they didn't try the ATS acquisition on this first opportunity [18:42:35] normal Madrid pass [18:43:24] something else I'd like to add to PA mfd is a manual station select [18:43:53] they acquired the ATS on the next rev [18:44:18] oh no [18:44:22] "We found a super Florida mosquito flying around [18:44:23] here a few minutes ago." [18:46:21] Günter Wendt probably not happy about it :D [18:47:29] what haha? [18:50:32] CAPCOM suggests adding an experiment on it to the schedule [19:22:56] ahh [14:29:38] hey [15:08:03] hey Nik [15:12:13] I am not sure if this is the best solution, but I am testing my new concept for the transmitting ground station [15:12:32] at least it keeps lock onto the ATS-6 satellite this way [15:12:55] It basically processes first which stations it has a signal to [15:13:37] and it uses the first one from that list if: there currently is no transmitting station or it just lost contact to the previously transmitting station [15:14:01] So this way it will keep using the same station as long as you have a signal to it [15:14:19] and then just picks the first in the ground station list that has the AOS flag set [15:14:48] this seems to give the desired behavior for ASTP, but I am not sure yet about other missions [15:18:24] lunar should be no problem. There is only ever 1-2 stations in AOS, out of a possible 3. [15:18:30] lunar orbit* [15:26:55] that should work, I would think [15:40:35] seperate lists for the LM and CSM? [15:48:57] not a new list, just the list of all ground stations we have already and their AOS flags [16:07:38] morning! [16:12:17] hey Mike [16:12:58] n7275, the only thing I changed about the ground stations is to make it a std::vector. That way it can handle that I am (optionally) adding new "stations" like the ATS-6 satellite [16:39:19] ahh, nice. are those now specified in the mission file? [16:54:39] n7275, I have added three things for the mission file. Completely override all the settings for a ground station (if you choose number 0 it adds the station instead of replacing it) [16:54:44] that's what I added the ATS-6 with [16:54:54] then an option just to change latitude/longitude of a station [16:54:57] no other changes [16:55:05] we can use that for the ARIAs and ships [16:55:19] and then an option to simply disable/enable stations [16:55:33] we can do mission specific stations [16:55:39] with that [16:57:44] no saving/loading of these settings though [16:58:24] so if we e.g. want to let the MCC move ships and ARIAs from where they were for launch/TLI versus reentry, that would be another set of changes [16:58:41] might be something nice in the future, but, not 100% required [17:08:00] awesome. no need to overcomplicate for now [17:11:59] yep, I'll give it all a test but for this branch I should have most changes done already. [17:12:09] so there should be draft PR soon [17:20:37] But I would definitely like to see ARIA and tracking ship AOS/LOS messages, that will be nice [18:01:13] I just had a case where I had AOS Bermuda and then AOS ATS-6 before I lost contact to Bermuda [18:01:37] so in my new system it will use Bermuda until LOS and I can't acquire the ATS-6 [18:22:34] out of curiosity, is ATS-6 at a fixed position, or using the state vector of an actual vessel? [18:24:48] vessel [18:24:52] I put a Delta Glider there [18:25:11] in our MCC code it already used both local and global coordinates for ground station [18:25:35] in case of the ground stations the local coordinates are of course fixed and it uses the Orbiter API function to convert to global [18:25:50] so for relay satellite it simply gets the global position of the vessel by name [18:25:53] and converts to local [18:26:10] and then the rest of the logic is identical for ground stations vs. satellites [18:26:47] ok there was one more place where I had to change something that only worked for locally fixed "ground stations", but, that all wasn't too difficult to get to work [18:27:59] I guess if we had multiplayer one person could fly an ARIA aircraft with this system lol [18:28:42] but I wanted this to also work for potential lunar farside landings that use relay satellites [18:28:52] so you can launch those satellites yourself [18:29:09] I added a lunar occulation check for relay satellites, so you can't cheat too badly [18:29:36] satellites need a line-of-sight to Earth with that [18:30:07] but no more complex relay logic than that [18:30:27] not in contact to a specific point on Earth, or satellite to satellite relay or anything like that [18:37:01] nice. I was thinking of lunar relay satelites. [19:06:30] cya! [14:51:34] hey [16:18:12] good afternoon [16:26:42] hey Matt [16:23:20] hey [16:48:49] morning! [16:56:07] what's up? [17:01:50] the AGC interface board for the CDU setup arrived yesterday [17:02:05] I have it mostly assembled, so should be able to finish that up and test it after work [17:02:35] also maaaaybe might be able to build up my first 16:1 dual resolver assembly today [17:02:59] the maybe is because the parts should all be here, but whether or not they properly fit is still up in the air :P [17:03:19] how's ASTP going? [17:04:49] nearly finished with the sleep period before rendezvous day [17:05:34] what, you don't have trust that all parts are built with the correct tolerances? :D [17:07:00] I'm trying to piece together a bunch of parts that I received no dimensions for and had to measure myself haha [17:07:17] the lack of trust is more directed inward than towards the manufacturers :P [17:07:34] haha ok [17:09:32] n7275, I think I solved the ATS vs. ground station confusion I had. The communication to the satellite was on different frequencies [17:09:50] So they have a whole separate S-Band system in the CM [17:09:53] everything twice [17:10:18] OMNIs for the normal S-Band communication, HGA for the ATS only [17:10:29] they even got separate signal strengths meters on ASTP [17:11:05] panel 2 for the omnis, panel 230 for a bunch of HGA switches and the signal strength meter for it [17:11:45] so with the different frequencies you could probably transmit and receive both at the same time, no problem [17:12:54] ... I don't know where that leaves my changed MCC code [17:13:14] I'd rather have it work like it did before, the ASTP HGA seems to be such a special case [23:09:21] thewonderidiot, who did you have manufacture your parts? [23:09:29] which parts? [23:10:31] the little lasercut plates I'm using for the resolver assemblies were made by sendcutsend [23:40:43] yes, those [15:47:55] morning! [15:48:25] hey Mike [15:48:33] what's up? [15:50:08] Have flown ASTP to the point where I could check if the Saturn IB insertion was any good. I guess I am semi-happy haha. [15:50:18] hahaha [15:50:26] not great, but not bad? [15:50:30] pretty much [15:50:51] a bit more out-of-plane DV than I expected [15:51:08] not as much as the old LVDC targeting though, that was just the operational trajectory numbers [15:51:32] Which, as ThatRedMelon had to notice, did not give a nice orbital plane [15:53:49] I am up to the point where I would start using VHF Ranging, which we can't do with the Soyuz yet [15:54:10] so I think I'll wrap up the changes I have done so far to the code and the ASTP scenario [15:55:04] and continue getting this new launch targeting tool release ready [15:56:34] nice :D [16:52:44] n7275, question for you [16:53:14] how much would there to be learned by getting a CM PCM running? [16:53:39] we're debating powering one up but are a bit... intimidated by the sheer number of connectors on the thing [20:30:57] night! [23:52:47] thewonderidiot, probably quite a bit could be learned [23:56:35] I have a lot of biases and assumptions about how it works from how dseagrav and Tschachim implimented it in 2005-8 [23:59:14] it would be really nice to know how how the sub-frame/frame/prime frame position relates to actually sampling a given value [02:46:50] how much do you think we'd have to wire up to test that? [02:59:09] I'm not sure, exactly, but I think you could demonstrate the functionality with 5 seperate inputs. [02:59:49] the question would be though, how much other stuff do you need to hook to it to make that happen [15:56:36] morning! [16:04:46] hey Mike [16:10:05] what's up? [16:19:01] my new targeting tool is now git tracked [16:19:04] but not released yet :D [16:21:28] But it's getting there where I am adding e.g. license headers to files [16:21:31] still lots of cleanup to do [16:25:29] exciting! [16:29:25] I'd still like to add an editing capability for the OMP maneuver constraints table, right now that's basically a CSV file [16:29:56] I guess at worst it just becomes a CSV editing text field [16:30:16] But then you don't need to add or changed any files with an external text editor [16:30:20] change* [16:31:40] ideally I would have something that looks like this: https://i.imgur.com/TfMOly3.png [16:34:16] with editing capability of everything in the table [16:34:25] but that isn't super simple haha [16:37:05] oh that would be very cool though [16:40:33] for sure [19:43:18] cya! [17:29:48] good afternoon [17:33:01] hello hello [17:34:58] what's up? [17:37:10] not much coding going on today, but I found a few nice papers on Orion guidance, navigation and control, so I am just reading those a bit [17:37:19] and you? [17:39:47] just getting back from a camping trip [17:40:23] oh fun, did the weather play along? [17:43:45] it did for once [17:48:06] no rain or wind. the sky's were so clear I swear I could just pick out M34 by eye at night [17:49:42] with so much luck it's probably constant rainfall from now on until winter starts :D [17:50:26] probably haha [17:50:28] we've had 30°C today. 18°C in 2 days. Looking at the forecast... I think summer might be over. [18:02:02] yeah, same situation here. it's still randomly warm-ish most days but it's getting colder in the nights...and some of the trees are looking less green in some places [18:11:48] ah I still have to watch Mike's most recent video about the CDU [18:28:04] ooo, I'll have to check that out too [18:52:20] it looks like some nice progress :D [19:18:26] afternoon! [19:18:31] yeah, things are progressing along nicely :D [20:05:46] hi Mike [20:10:05] hey hey [16:11:06] wait what? [16:11:11] I wasn't here [18:38:47] huh? [18:40:39] indy91_ [18:45:16] well I am me, I am pretty sure [18:45:42] But I joined as indy91_ because indy91 was already here, who then left a few minutes after I joined [18:46:23] the ping timeout timer is counting from when I joined, so something must have gotten confused and joined me twice or so [18:46:28] in any case, hey Matt :D [20:40:08] hello. I forgot to look at my irc client again for a bit, whoops [20:45:50] well my client apparently looked at IRC on its own at first :D [20:53:21] requesting ATS-6 TLE, I almost got all data since it launched, but then I remember it is geostationary and it is still there so I don't really want almost 50 years of useless data :D [20:56:37] And I think I'll put it as a Carina in the ASTP scenario, that's really the only stock Orbiter satellite [20:57:29] night! [14:42:09] good morning [14:44:02] hello hello [14:44:09] turns out they have no ATS-6 TLE [14:44:16] not for 1974/1975 anyway [14:45:56] I'll just have to add it to the scenario with the scenario editor, no big deal [14:58:25]