[12:45:04] NASSP Logging has been started by n7275 [12:45:06] hey Alex [12:48:53] hey [13:35:58] got the csm functioning how I want it with my new antenna updates last night [13:36:41] just need to transplant those into the LM and I'll be ready for someone to find all my bug-- review a pull request :) [14:28:08] hey [14:36:30] hey Niklas [14:36:46] n7275, looking forward to giving it a test [14:43:58] definition of feature creep. Trying to clean up meshes a bit for the cue card update -> delete Apollo 5 nosecap and LM-1 meshes from Saturn IB class -> experimental AS-203 scenario broken -> work on AS-203 with docked stages [15:00:48] wow haha [15:01:46] well if they all part of the "clean up meshes" theme its fine [15:03:25] I can maybe add the improved AS-203 scenario first [15:03:34] it doesn't do much [15:04:23] we currently have one under Broken Scenarios [15:04:37] even this new one isn't correct, it has a wrong sort of nosecone [15:04:46] looks identical to Apollo 5 right now [15:10:13] morning! [15:10:24] hey Mike [15:24:35] AlexB_88 my branch for it should be up to date on GitHub [15:31:06] ah ok I will take a look [16:56:01] indy91, there was a change to the moon config recently [16:56:03] "JCoeff" [16:56:42] nothing significant [16:56:47] I am testing with a Apollo 15 TLC scenario, pre MCC-2 [16:57:02] Apollo 8 AGC only had a J2 coefficients, that's why we had this as well [16:57:14] the J4 is quite small [16:57:40] the proper behavior with apolune and perilune altitude changing over time can't be simulated in Orbiter as-is [16:57:52] and when I put an option 4 MCC, LOI (code 2) and DOI, there is a large DVz component that I can seem to fix by adjusting REVS1 like I could before [16:58:58] I've not really seen any case in the past where we even need to adjust the REVS1 at all [16:59:19] are you sure the DOI is on the correct rev etc. [17:00:31] and did you mean "can" or "can't" [17:02:33] well I had tweaked REVS1 so that option 4 MCC + LOI (intersection) would lead to a DOI with DVZ very close to 0 [17:02:56] and that worked perfectly some time ago [17:04:57] I've been discouraging people from doing that procedure, because it's lengthy, requires the MPT and I've not seen a case in a while where the DOI DVZ is more than 10-15 ft/s [17:05:53] right I agree it shouldnt be required [17:06:20] but I am bringing it up becasue the unmodified value right now shows DOI to have a DVz of 85 fps [17:06:32] which is higher then I remembered [17:07:20] I wonder if the trajectory on my Apollo 15 scenario is bad...but I seem to remember using it before for testing. weird [17:08:44] just to be clear I am using an Apollo 15 TLC scenario at about 30 hours GET, with an option 4 MCC (no constraints changed) and LOI and DOI on the MPT [17:09:16] is your LOI TIG close to flight plan? [17:09:25] within a few minutes [17:15:21] I mean I try it with your scenario to see what is up, but nothing in the relevant targeting has really changed since you probably last used this scenario [17:15:25] I can try* [17:18:14] https://www.dropbox.com/s/om702az1qa39uyw/Apollo%2015%20-%20Before%20MCC-2.scn?dl=0 [17:27:07] I get -4.4 ft/s for DVZ [17:27:49] it could be a problem of short burn logic, I haven't properly solved an issue there with the iterate option [17:28:24] for MCC-2 I used: don't iterate, and put in 4 jets 0 seconds ullage [17:28:36] instead of default, which would be 15 seconds ullage [17:28:42] that is a change that it would default to 15 [17:28:58] same options for LOI [17:29:11] and I did constrain the LOI time to get it a bit closer to flight plan [17:34:30] ah I see [17:35:33] so I don't know where you did it differently that affected the DVZ so much [17:44:33] the technique to get the LOI TIG close with the constraints didn't work all that well for me [17:44:37] because it had a jump [17:45:00] in one case it was a minute early and then suddenly it was 2 minutes late [17:45:09] only difference was 1 seconds different constraint times [18:06:52] right [18:07:09] I am off to work, I will do more testing in a few days [18:07:11] cya! [18:29:53] indy91, I added a new header file in my branch for clbkGeneric arguments. thoughts on making that a bit more foolproof future devs? [18:36:37] also, is there something I can check to see if(uplink in progress)? [18:46:54] that looks fine to me [18:47:04] what type of uplink, any? [18:47:06] or from the MCC [18:48:01] because the MCC uses a cheaty, non TCP/IP way to do the uplinks [18:48:11] so the only general place to check would be the DSKY [18:49:49] hmm [18:50:00] actually not general enough as not all uplinks are to the AGC [19:23:43] I wanted to make some kind of "don't switch stations of we're uplinking" feature [20:08:46] I think that is difficult to do with the way the MCC gives uplinks to the PCM [20:09:52] I didn't implement it but to me it seems like the uplink data is given to the PCM as a whole and then cheaty, MCC-specific code in the PCM processes it [20:10:00] so you would need to check on something in the PCM [20:12:35] okay [20:15:01] maybe mcc_size ? [20:16:08] ah yes [20:16:20] the MCC already does that [20:16:22] if checks on [20:16:23] if (cm->pcm.mcc_size == 0) { [20:16:29] and the same for the LM [20:16:38] before it continues to the next MCC substate [20:45:39] night! [14:35:04] hey [14:46:21] hey [14:49:11] LM ground station tracking is now implemented too [14:50:29] oh great [14:54:49] the LM steerable is a bit harder to test in LEO [14:57:40] ugh, I want 4:3 MFDs... [14:58:21] always having problems squeezing some MOCR displays on 1:1 [14:58:26] and apparently I forgot to initalize the Transmitting ground station pointer [15:14:31] what if you inset a 4:3 window into the MFDs? [15:18:12] ah yeah, I think I had experimented with that at some point [15:18:25] the 2D panel MFDs can't be resized and then it looks really small [15:18:41] I think that was the main obstacle to doing that [15:59:16] hmm yeah I can see that being problematic [16:05:54] morning! [16:06:30] hey Mike [16:07:11] hey Mike [16:08:01] indy91, do you do these MOCR displays on a character grid or just x,y position? [16:10:09] I am doing it like this most of the time: [16:10:10] skp->Text(2 * W / 44, 14 * H / 26, "GMTI", 4); [16:10:20] W is the total width of the MFD, H is height [16:10:49] always a lot of work to fine adjust this [16:10:55] I should probably use a more consistent system [16:11:12] grid like where I just put in the number (ot of 1024 or so) where I want to position it [16:41:07] I'm thinking of something like how ncurses does positioning [16:47:15] how does ncurses do it? [16:53:02] you'd have a fixed grid e.g. 74x53 characters, and then you'd have some addtext(row, column) function [16:58:31] fixed grid sounds interesting, that would solve a few problems. But it would only work in the External MFD when you resize the MFD to exactly the needed size [16:59:10] The only simplification to my current system would be to assume that the MFD is always e.g. 1024 x 1024 [16:59:36] so instead of a "100 * W /1024" that would simplify to 100 calling the function to write the text [20:44:55] night! [15:15:30] good morning [15:22:38] hey [15:40:56] seems like ground station tracking is taking shape! [15:46:33] yes. a few more things to finish and it'll be ready for review [15:46:47] full review that is [15:47:23] I wrote two comments on Github [15:48:03] what happens right now without an MCC vessel in the simulation? [15:49:43] good question. [15:50:48] nothing gets written to those variables I guess? [15:51:12] you have initialized them so it probably thinks MSFN has gone to lunch break [15:52:45] ideally there would be no ctd... [15:53:21] assuming I actually check for that, it would be like all the ground stations were off [15:53:29] yeah [15:54:03] I can add the minimal MCC vessel lines to the Apollo 12-17 launch scenarios soon [15:57:07] okay. I still need to change the ground tracking check so that it just disables mesages, should be an easy change [15:58:36] one other thing I would like to add at some point is some kind of feedback for the user on VHF signal strength. not sure what the best way to do that is though [15:59:55] morning! [16:04:47] hey Mike [16:16:56] hey hey [16:24:19] maybe we could implement a push to talk key, and do something with it [16:59:42] as in, play a sound effect, bit realtime audio processing [16:59:53] s/bit/not [17:01:17] can we save the audio and sell it to Google or so [17:21:06] haha [17:22:07] okay, that one can go on the list for potential 2023 April fool's jokes [18:33:32] my current PR is actually a lot less scary than it looks. Most of it is find + replace for a data table that now contains 3 instead of 1 set of data [18:50:14] i will try to review it tonight. ran out of time last night or I would've done it then. [18:51:13] sounds good [22:57:05] thewonderidiot, how familiar are you with gnuradio/gr-satelites? [22:57:24] if this were an RPG [22:57:30] I would be at level 1 with 0 experience :D [23:11:26] I read the manual. it didn't drop any xp [23:11:50] I haven't ever tried to use it [23:11:54] but that resonates with what I have heard [23:13:49] I want to write a telemetry processor for NASSP, something I can produce graphs, or data files of individual parameters. [23:14:28] at the very least I may take inspiration from the way they specify frame formats [23:15:53] obviously the intended use case is demodulating and then decoding PSK signals, but but gnuradio also accepts TCP input [23:16:26] oh man [23:16:48] have you looked at things like openmct or ball aerospace cosmos? [23:17:37] I have not. but I'm on my way to the Google machine right now [23:18:12] they may or may not be somewhat aligned with what you're trying to do [23:29:08] that might do it. my goal was to facilitate some interoperability, without reïnventing the wheel unless I really had to [23:38:39] also, if I have to go through the exercise of typing up some massive JSON structure of our telemetry formats, it would be really nice it it worked with more than just my python/matplotlib hackery [23:45:17] hahaha yeah for sure [12:33:44] hey [12:44:41] hey Nik [12:46:20] I got a little stuck last night. I'm trying to eliminate the flood of AOS messages that happen on scenerio load by saving the active ones [12:47:29] there is a flood of AOS messages? [12:47:36] oh maybe shortly after TLI I guess [12:47:57] close enough to Earth for the low range antennas, far enough to be actually have line-of-sight to a bunch [12:48:27] when you first load a scenerio in earth orbit, it checks what stations are in AOS [12:49:34] yeah [12:49:41] and that is usually like 1 or 2 [12:49:51] so it has to run through the list to check them, because it does this in list-order, the "most recent AOS" becomes the transmitting one [12:50:23] I was testing this over central US, so kinda worst case [12:50:28] 4ish [12:50:29] ah true [12:52:09] so you may be locked into Bermuda when you save, but when you reload, now it's Grand Bahama [12:53:49] the weird part is, it will load the AOS flag for some stations, but not for others. I probably have a really dumb typo somewhere. [12:56:02] we do have stations where the name isn't unique [12:56:26] two different Goldstone antennas for example [12:56:30] maybe that is the problem? [12:56:42] you could use the "Code" instead of "Name", those are unique [12:57:50] hmm but looking at your loading code that shouldn't be a problem... I think [13:00:14] should be easy to debug though, just build the MCC in debug mode [13:02:10] the for loop with the [13:02:11] if (strcmp(GroundStations[i].Name, TransmittingGroundStationName) == 0) { [13:02:21] should probably be outside of the while loop on the scenario lines [13:02:31] char GSLoadAOSNames[128]; [13:02:32] too [13:02:41] oh whoops [13:20:13] my little for loop there becomes a nested loop then :/ [13:45:16] I'll just use the site code, and flatten my loop [13:45:54] I'm remembering my "better to write simple code twice..." comment from the other day [14:13:22] if you want, we could probably add a "telemetry site" code to some of the uplink pages, where appropriate now [14:23:27] those telemetry sites are selected manually for the uplink. But I guess the logic could now check if the proper one was selected for the uplink to work [14:31:16] yes, exactly [15:00:36] maybe something for MPT mode where the displays are available that clearly show you which tracking stations are in AOS [15:05:55] wouldn't 1503 work for that? [15:07:11] quick question that I may have asked before and forgotten: is non-MPT mode an NASSP thing or did the real RTCC have something like that too? [15:07:12] yeah I am pretty sure that is the display the CAPCOM is looking at when he says "we will hear you again from Honeysuckle at 2:05 GET" [15:07:28] very much a NASSP only thing haha [15:08:37] I took some months building up this realistic structure around the MPT in the RTCC MFD and kept it separate from the normal RTCC MFD calculations [15:09:09] at some point I wanted it to replace the older calculations, but it's a lot of work maintaining the weights and state vectors etc [15:11:16] the main difference of setting this "MPT mode" as active or inactive is that all the maneuver calculations etc. will try to get state vectors and weights from ephemeris and the MPT [15:11:35] and in non-MPT mode it gets them from the current vehicle you have the MFD open in [15:11:54] I think the long term plan is a bit of a hybrid [15:12:56] if I can automate the weight and state vector stuff then I might as well generate the ephemeris etc. from that [15:13:12] like MPT mode just without a maneuver in that table [15:13:51] just initial state vectors stored in the right place and making use of the MPT header, which is where the initial weights, vehicle configuation etc. are stored [15:21:53] ahh okay [15:23:34] what would be a bit excessive maybe is to do a ephemeris update every time you want to do any calculation in the MFD [15:23:59] regarding uplinks, I think you would pick a site, and if it's not in AOS, it would go nowhere. it it is, but it's not the active station, it would switch that station to be the active station, and if the station is the active one, it would just do the uplink [15:34:37] Hello! [15:34:50] I have not. [15:35:04] I did have some spare moments to look over your PRs [15:35:37] So. What did I miss in the last 3 weeks? [15:36:01] haha you approved the one PR within minutes that needed more lengthy testing and where Alex did find one more bug before it got merged :D [15:36:29] uhh, ggalfi's PR for acceleration data still waiting for you to review [15:36:51] I duplicated our astronauts for EVA, but you have already seen that [15:37:45] Oh really lol? I do admit that I was less thorough than normal. [15:38:37] Yep, I might do that in a little bit. Got a couple of things to organise still. I got home yesterday and woke up at 2PM today. [15:39:22] I did not manage to sleep on my flight back as I had hoped [15:40:45] oh wait, was this your America trip? [15:40:51] Yeah [15:41:03] did you find some AGC nerds on the west coast? [15:42:07] Just some random guy that kept a CDU in his apartment. Took me to some other guys' basement to fix his NASSP install and play with an old radio. [15:42:43] if that's the basement I am thinking of then there is a lot to see there [15:43:50] nice sub [15:44:01] I can confirm that the DSKY color NASSP has now is pretty much as close as we can get to the real thing :D [15:45:03] that's very good to know :D [15:46:42] I also saw Endaevour and the ASTP CM [15:47:48] and the Eiffel Tower [15:48:08] Haha yep [15:51:32] looks like a very nice trip. But also a lot of driving through the desert haha [15:53:22] Yeah, especially going from Bakersfield to Williams and from Las Vegas to Lake Tahoe were long. I made sure to have enough music and I was able to video call from my phone a lot so it wasn't too bad. [15:54:39] I was driving a 2021 Toyota Corolla and it was great. It had radar assisted cruise control, and because it had an automatic gearbox would bring you all the way to a stop in a traffic jam following the car in front of you all the while the set point was at 70mph. [15:56:17] Lane assist also kept the car in your current lane so all I had to do was occassionaly apply pressure to the steering wheel and make sure there where no cars making odd moves. Driving through the empty desert was really comfortable with a car that essentially drove itself in that situation. [15:59:04] well Americans are all about that comfortable driving because they have to do it a lot. The average German would be too proud to use all those features, including automatic gearbox :D [16:02:34] It's a challenge to find rental cars with a manual gearbox. If at all it'll be under the "special" category. I didn't mind it at all. I was worried enough with getting used to US road rules after picking up the car in the middle of SF. I was very glad to be in a more rural area to start getting used to driving there. Coming back into SF wasn't as bad as the first time there. [16:04:07] yeah cities are not beginner friendly haha [16:06:03] I gotta remind myself that turning right on a red light no longer applies now that I'm back. :P [16:07:44] we have a "Right turn on red permission" sign for that [16:07:58] got a nice story, too [16:08:05] "In Germany, right turns on red are only permitted when a sign is present at the traffic light, after a complete stop. This rule was first introduced in 1978 in East Germany. It was derided as the "socialist right turn" in West Germany, which planned to eliminate it after German reunification in 1990. However, a public backlash put an end to the plans, and the practice spread to the rest of Germany in 1994. Half of the 5,000 turn-on-red [16:08:06] intersections that existed in 2002 were located in the former West Germany." [16:11:24] Socialist right turn? Lol, tell that to a patriotic american. [16:16:49] it's only socialist if you need a sign for it [16:59:43] lol [17:00:27] welcome back Thymo! [17:04:17] somehow Guenter survived your whole vacation, unlike last time [17:13:16] looks like a fun trip [17:54:06] Yeah, I'm glad it did, it's hosting a pretty important VPN now too. Last year was no fun. [17:56:55] hey while I'm thinking of it, you had mentioned wanting to add or impliment some kind of networking API at some point, right? [17:57:32] hey hey! [17:57:38] those sound like a bunch of weirdos you met [19:00:09] n7275: Yeah [19:00:23] Soon™ [19:00:44] I saw you had some ideas too? [19:02:58] yes, although I have no idea what I'm doing [19:04:27] my thought was to make an Orbiter plugin that connected to all the various ports we have (and will have), and allowed external programs to request that data/send data back via something like http get/post [19:04:55] Right so multiple REST APIs [19:05:51] I was planning on putting everything behind a single gRPC API and you can interact with different systems through it. You don't want to open a port for each and every service you want. [19:07:17] The nice thing about gRPC (and also OpenAPI if you want to do REST) is that you can specify a generic spec and generate servers and clients for most mainstream languages [19:07:19] https://grpc.io/ [19:08:07] gRPC also allows streaming. REST is polling. If you want to do telemetry a streming protocol would be best. [19:08:13] s/strem/stream [19:32:17] oooo okay [19:51:09] I have no idea how any of it works but it looks very powerful [19:59:06] I know what I'm reading this weekend [20:37:47] I know I've seen some bit error rate graphs, if we ever want to make telemetry/uplinks more "interesting" [20:54:38] I see you starred AIT-GUI? Is it any good? [20:54:43] n7275: [20:57:45] not sure yet, I started it for "further investigation" [09:53:52] hey [09:54:06] hi [10:03:56] hey guys [10:14:05] rebooting for updates