[14:42:41] NASSP Logging has been started by indy91 [14:42:43] good afternoon [16:14:12] hey Niklas [16:16:41] I'll try to impliment VHF ranging this week. [16:20:16] ah great [16:20:27] by then I should have some good testing scenarios for you [16:23:04] then you don't need to cheat yourself a Skylab into a position where VHF ranging actually works [16:23:48] don't think I'll get in VHF range today [16:23:52] but maybe tomorrow or so [16:49:54] morning! [16:55:19] hey Mike [16:55:24] what's up? [16:56:25] launching Skylab 2 again, this time with launch targeting for the correct launchpad... [16:57:04] that always helps :D [17:04:47] you definitely can't tell us we are putting too much work in something we only potentially will get, now that you are really starting the source reconstruction :D [17:05:10] hahahaha I know, I can't help but also be excited [17:25:56] n7275, the maximum range for VHF ranging is based on some calculated signal strength, not a hard cutoff value, right? [17:26:24] because in Skylark they made a change for this [17:26:32] correct, I believe it's -120 dB [17:26:45] maximum range value it can send to the CMC is 327.67 NM [17:26:55] but they expected longer ranges [17:27:20] and the data from VHF ranging wraps around, so beyond 327.67 NM it sends actual range minus 327.67 [17:27:28] and Skylark can deal with this [17:28:08] I thought some of the earlier ropes could do the wraparound thing too? [17:28:17] hmm, maybe [17:28:25] I see a Skylark PCR [17:28:41] our VHF ranging system already sends the range value in this way [17:28:51] didn't think any other CMC could deal with it yet [17:29:40] in fact I thought I remember seeing it a little over 400 when I was testing the implimentation [17:30:20] I coulld be very wrong about that though, maybe I remember expecting to see it? [17:30:37] Skylark had a flag change associated with this [17:30:44] EXTRANGE, I think [17:33:11] oh, it would show more than that maximum range on the EMS right now in NASSP [17:33:21] but the range sent to the CMC is limited [17:33:27] not sure if that is correct behavior [17:34:51] so if in NASSP we have a sufficient signal strength to get a tiny bit above 327.67 NM, then it would show the actual range on the EMS [17:34:59] and CMC gets a tiny bit more than 0 [17:35:22] you think the EMS should wrap too? [17:35:33] maybe it's the same source of signal, have to check [17:35:45] it could very well just be a scaling thing for the CMC though [17:36:40] but in terms of "P20 can process larger ranges", I am pretty sure only Skylark can do that [17:37:26] because it of course needs extra logic to determine if the data is actual range or modulo [17:38:29] if I understand the Artemis GSOP correctly, it does a check if the calculated (not measured) range is beyond 327.67 [17:38:38] if it is, it won't process VHF range [17:45:27] hmm, Systems Handbook says, for the EMS interface [17:45:42] "Maximum unambiguous range: 327.68 NM for initial range display" [17:46:01] sounds like it wraps to me :P [17:47:28] I think I worked on that in late 2020. my memory only has a shelf-life of like 8 months [17:48:00] same [17:48:34] you probably did over 400 on the EMS at least, because that's current behavior :D [17:48:49] and I have to check if this modulo is a later addition of mine [17:49:22] but the CMC can't really have processed larger ranges [17:49:27] 327.67 [17:49:29] 32767 [17:49:32] in octal [17:49:34] 77777 [17:49:48] pretty sure that is the scaling [17:50:11] 32767 is a familiar looking power of two :) [17:50:18] minus 1 [17:50:34] yeah, minus 1 :D [17:57:50] still searching for a definitive hint that the EMS behaves like this, but I'll likely change it [17:59:11] that Systems Handbook line could still mean that it shows something useless and not actual range minus 327.67 [17:59:22] or maybe it's just my reading comprehesion :D [18:04:58] lol yeah, the statement that above 327.68 it is ambiguous, is itself ambiguous [18:06:18] I was literally just trying to making a joke about that [18:06:37] hahahaha [18:07:36] [18:27:22] I believe the EMS register in the VHF ranging equipment works the same as the one for the CMC, so it displays 0.01 for 327.68NM [18:07:42] [18:31:25] yeah, the new Skylark document explicitly says that 350NM range is 2232 (decimal) in the counter [18:07:48] [18:32:14] so 327.68NM is probably 0 [18:07:50] [18:33:36] sounds right [18:07:51] [18:33:54] that's really funky [18:07:53] us in 2018 [18:08:24] but "counter" could also be the counter for just the CMC, I need to check where I found those values again :D [18:09:24] yeah that's the Skylark User's Guide [18:09:38] and it does not explicitely say the EMS also shows it like the CMC [18:27:17] n7275, maybe with the Skylab MCC I will schedule updates at AOS of a specific ground station. on a specific rev [18:27:40] the passes can be quite short when the PAD or uplink are given [18:28:05] and it feels a bit unrealistic if the uplink pops up and you get the AOS message only afterwards :D [18:28:59] something to experiment with anyway [18:31:40] ok already potentially dangerous for a US pass, because "has signal" on rev 2 can be the beginning or end of rev 2... [18:34:02] would need to be at the actual AOS [18:38:10] I think the only logic I have for stations is not to change to the next one while uplinking [18:39:19] scheduling might benefit from some RTCC math, moreso than it does from my hacky code [18:40:37] for non-MCC missions, I still want to add a "manual station select" to one of our MFDs [18:41:11] right [18:41:32] the AOS/LOS calculations are definitely reliable [18:43:19] hmm but you are right [18:43:31] it's not just the station switching thing during uplinking [18:43:41] it does not detect AOS during uplink [18:44:03] so I'll probably not use that for now [18:44:37] I mean, when the MCC uses it the MCC would be waiting on the next thing to happen, so an active uplink would be highly unlikely [18:45:29] when the MCC would use the AOS flag* [18:47:06] our vessels and stations have no VHF functionality right now [18:47:31] other than ranging of course [18:49:04] maybe I could just check if TransmittingGroundStation is not 0? [18:49:24] but that's S-Band only I believe [18:49:36] bad for cases where they gave a PAD via VHF [18:55:05] maybe I need a separate vhf and s-band flag [19:02:21] sounds complicated [19:03:12] maybe a flag for "is any ground station in AOS" [19:03:22] so one flag for all of them, one just for uplink capability [19:04:21] that are flags useful for the mission tracking [19:04:39] I could check on the voice flag for PADs only [19:04:52] otherwise if there is a TransmittingGroundStation like right now with that flag [19:05:38] this is why they invented satellites... [19:17:44] careful what you are saying [19:18:37] https://en.wikipedia.org/wiki/ATS-6 [19:18:46] on ASTP they flew a HGA [19:19:01] and tracked this as a data-relay and tracking satellite [19:19:30] so we need to implement a system in the MCC that enables us to do that :D [19:20:10] it might not even be that bad actually [19:20:33] just something that dynamically updates lat/long etc. for the satellite [19:20:42] and then it would be treated just like a ground station [19:21:37] could make an actual satellite, and give the MCC a pointer to it's position [19:21:47] yeah, that's basically what I mean [19:22:00] actual satellite, lat/long are updated in the MCC [19:22:11] and then the MCC logic treats it like any other ground station [19:22:22] just radius is hardcoded to Earth radius right now [19:22:26] that would need to be changed [19:22:32] but it should anyway [19:22:39] to take station elevation into account [19:22:49] the satellite would just have a much higher elevation [19:24:53] and a way to have mission specific stations I guess [19:29:22] probably should add that for ARIA too [19:31:25] could be as simple as adding a feature for our mission file [19:31:33] where you can override a ground station [19:32:31] ha [19:32:41] we already have empty ground station slots for ARIA [19:32:52] so we really only need a way to set values to it [19:33:32] having them in different positions for different part of the mission is where it would get tricky [19:39:30] obviously manually flying then is the only solution [19:39:52] *them [19:40:29] clearly [19:44:18] no obviously it needs to fly around automatically, with an autopilot I have to implement [19:48:50] ahh, yes [19:49:36] the part where it works it 70x would be fun :) [19:53:16] I can't type today. I give up lol [20:04:35] only the essential projects for NASSP that we are thinking about :D [20:11:38] just did the NC2 burn, I am in VHF range now [20:12:03] want that scenario? [20:12:05] like 280 NM [20:12:16] I have scenarios with more [20:12:18] range [20:13:23] that'll work, maybe one or two closer and further away [20:14:33] closer you will have to wait until tomorrow, but further away I can give [20:16:29] haha, okay [20:17:05] docking should be interesting with no target [20:17:18] I'll tackle that when I get there :D [20:17:25] still a few maneuvers to do [20:17:41] 467 NM, maybe a bit too far, or do you want it? [20:18:17] and then I got one with 356 NM [20:18:29] all other scenarios are much further away even [20:19:12] in this Skylab 4 checklist they are supposed to try VHF ranging for the first time at 411 NM [20:22:29] I'll take whatever you have [20:23:00] ok, I'll give you those 3 then [20:23:44] are you flying this in the Orbiter2016 branch? [20:24:29] Skylab MCC [20:24:42] not sure what happens when you load these actually [20:24:48] probably nothing [20:25:04] no further MCC updates of course [20:25:29] I will test Orbiter2016 as the basis for my SkylabVHF branch [20:25:43] yeah, should work fine [20:25:51] I don't even use the fixed Artemis version for the rendezvous [20:25:57] just doing the ground solutions for maneuvers, for testing [20:26:08] so this is completely Orbiter2016 branch, except the MCC updates [20:26:29] thanks [20:27:20] yeah I am pretty sure these scenarios will load fine [20:27:42] it will just not switch/case to the new Skylab mission states [20:29:02] you wouldn't be able to complete the rendezvous unless you use the RTCC MFD, but I can supply you with scenarios that are closer to Skylab tomorrow [20:46:17] good night! [14:57:12] hey Niklas [14:59:05] hey [15:22:29] I made some progress on the VHF ranging, still a bit more to do, mostly on the CSM side [15:26:57] on the CSM side? [15:27:27] oh [15:27:29] if (utils::IsVessel(pVessel, utils::LEM)) [15:27:30] stuff like this... [15:27:50] needs to be made more generic for sure [15:27:55] also with ASTP in mind [15:28:28] I'm continuing with the Skylab MCC, I won't bother doing much in terms of onboard rendezvous calculations, just flying the MCC solutions [15:28:37] through TPI [15:28:41] and that's where I stop [15:30:31] a have a few RTCC projects that I want to do before Skylark, but I think the next priority is Skylab attitude control [15:30:35] I'll start with the thrusters [16:03:53] I know I've had several ideas for making stuff like that more general purpose, none of them seem all that good though [16:06:26] either each vessel needs to keep of some one-to-many relationships, or we need a "connector server" [16:22:11] morning! [16:28:09] hey Mike [16:52:39] hey [16:53:26] what's up? [16:55:21] finishing a Skylab rendezvous as far as I will take it with the MCC support [16:55:39] no point trying to dock yet, no attitude control on Skylab :D [16:56:22] hehehe [16:56:23] I think I don't even need to do the TPI burn for now [16:56:36] just checking that the MCC-H solution is good [16:58:33] and it is [16:58:41] nice :D [17:02:10] draft PR up [17:02:17] now Skylab attitude control research [17:05:46] I've had a system with a MATLAB script for the SM RCS thrusters that did the coordinate system conversions, I can probably reuse that code [17:06:54] If you add them before the ShiftCG you can probably just put them in Skylab coordinates [17:07:04] yeah that would be great [17:07:19] makes these things much easier [17:07:48] I already roughly know the attitude control modes [17:07:58] attitude hold, solar inertial, LVLH tracking [17:08:20] maybe I can just implement a keyboard combination in the Skylab vessel to cycle between them [17:08:35] and a free mode of course [17:48:12] hmm [17:48:20] I'm looking at our Skylab mesh in Blender [17:48:30] could it be that it is a few meters too short? [17:54:14] I've always noticed that a bit, but wasn't sure [17:54:24] just looking into measurements for the thrusters [17:54:38] I think it's like 3 meters over all... [18:46:32] yeah, it's not even close to the right shape [18:46:35] or size [18:47:31] starting from the Skylab1973 mesh sounds more tempting now [18:47:43] the creator is occasionally online on the forum [18:47:49] maybe we can get permission [18:48:27] I had taken some measurements in Blender and from what I saw it looks quite good [18:48:39] I'm pretty sure these thrusters would appear behind the end of our Skylab mesh [18:49:07] I would hate to use wrong thruster positions just so that it doesn't look terrible with the mesh [18:52:03] the skylab1973 mesh even has thrusters modeled [18:53:33] it's a Spacecraft3 vessel, right? [18:53:37] no module [18:54:19] oh you mean it actually shows the thrusters on the mesh :D [18:54:25] as opposed to our mesh... [18:55:31] correct [18:56:04] in reality there thrusters are approx. 20 meters from the center of the coordinate system [18:56:15] that's beyond the end of our mesh [18:56:26] the thrusters* [18:56:48] I would imagine by quite a bit... [18:57:07] the MDA and AM are way too short on ours [19:47:52] I can message the author if you want [19:48:59] sure [19:49:17] I've also been messaging people on the forum, to recover Skylab documents lost from NTRS :D [19:56:14] :) [20:01:39] if you find any computer-related info I'm interested [20:04:09] ATMDC? [20:04:27] https://specialcollections.wichita.edu/collections/ms/87-08/87-8-a.html [20:04:36] Apollo Telescope Mount Digital Computer Program Definition Document [20:05:14] I have this feeling though that this collection isn't easy to get to. Maybe I am misremembering, but we might have already tried to get something from there [20:07:27] but this document would be quite great to have [20:07:37] pretty sure it would also have everything for attitude control [20:10:13] no, you're not misremembering [20:10:20] that collection is a black hole :( [20:11:34] that's unfortunate [20:12:21] would it do any harm to send an email? [20:13:56] no, no harm [20:17:10] I was reminded while scouring ebay for potential skylab documents that this is still listed lol https://www.ebay.com/itm/354235787668 [20:19:30] https://www.ebay.com/itm/115897265361 has an "APCS Simulation Laboratory Handbook" [20:31:54] well that's twice what it was yesterday... [20:32:01] lol [20:33:14] "I Am Altering the Deal, Pray I Don’t Alter It Any Further" [20:35:41] lol [20:52:00] night! [15:35:17] .tell indy91 I've made a bit more progress on the CSM-Skylab Connector/VHF project. CSM and Skylab are talking now, but now I need to fix the LM [15:37:14] oh hi [15:38:08] was just telling Guenter some things [15:38:56] was he telling things back? [15:39:00] ah good :D [15:39:52] connectors have a GetConnector function [15:40:50] what i've been doing is calling GetConnectorVessel, which requires a pointer to the vessel, GetConnector takes just connector type [15:41:40] I'm a bit confused what the difficulty is [15:41:48] actually, I'm a bit confused by the current code as well [15:42:01] why does there even have to be a check on the LM class? [15:42:33] oh [15:42:44] right, connector class thing. I was only looking in the timestep [15:42:50] well aparently I was more than a bit confused back when I implimented that [15:42:52] not VHFAMTransceiver::Init [15:43:26] because there does *not* need to be any vessel pointers involved [15:43:40] connectors are already smart enough to do this [15:44:18] It might take me an extra few days, but this PR should have a fairly large amount of get-pointer-to-vessel code removed [15:44:54] that would be great [15:45:10] you do that, I'll go to my own confusion which is coordinate systems for Skylab attitude control :D [15:46:56] also re: my "many to one" connector comment from yesterday, there does exist already a MultiConnector class [15:47:43] right [15:48:22] ok if I put the Skylab thrusters 3 meters too far forward then they look about right with out mesh... [15:49:04] 3 meters off, is that all :) [15:51:30] I messaged Usonian last night, waiting to hear back. [15:51:39] as we said in the mechanical engineering courses: "probably a tolerance civil engineers would use" [15:52:05] morning! [15:52:10] sounds about right haha [15:52:14] hi Mike [15:52:16] hey [15:52:47] that's why you get at a university with both large mechanical and civil engineering departments haha [15:52:51] that's what* [15:54:02] Clarkson was similar haha [15:55:05] for some reason the department offices were on opposite sides of the campus... [15:57:57] yeah weird how that works [16:52:44] n7275, there is an issue with the Skylab VS project, can't build it in debug mode in VS2017 [16:52:48] probably some settings to do [16:53:50] oh whoops, I don't think I properly set up a build configuration for Skylab/debug [17:04:33] I presume it's similar settings between release/debug in our other projects. I can add that later today probably [17:16:01] yeah no problem [18:13:27] I'll forward it later, but I got a massage back about Skylab1973. apparently it is already under GPL2 because the addon uses some NASSP meshes [18:13:40] so we should be good there [18:18:32] awesome [18:20:09] one challenge with this mesh though is that it is folded in its default state [18:20:14] so we need to figure out the animations [18:20:23] or maybe translate the SC3 animations into code or so [18:39:21] I seem to recall that not being super hard [18:39:40] 2007-me could figure it out [18:40:30] will be fun to see the Skylab unfold itself [18:40:43] commanded by a LVDC flight sequence program of course [18:43:11] I imagine the full ATM deployment is quite slow [18:44:10] StraussZarathustra.wav [18:53:04] yeah [18:55:40] I'm not having a good time with Sklyab coordinate systems... [18:55:59] I'll pass that job on to future me [18:56:19] in the process I also learned [18:56:25] our IMU code is confusing [18:56:47] :surprised-pikachu: [18:57:16] that sounds like it has a lot of potential to be one of the more arcane pieces of NASSP code :D [18:58:12] having had my hands pretty far into that one recently, what specificially? [18:59:14] what is right handed, what is left handed, what actually are the IMU gimbal angles it calculates [18:59:48] newAngles = getRotationAnglesXZY(t); [18:59:52] DriveGimbalX(-newAngles.x - Gimbal.X); [18:59:56] minus newAngles??? [19:00:06] both minus [19:00:19] so one of these is not the actual current or previous gimbal angles but the minus of it [19:01:20] so, there are gimbal angles, and there are euler angles to the platform from the vessel local coordinates [19:03:59] right [19:04:28] getRotationAnglesXZY() gives the actual gimbal angles [19:05:09] based on the rotation matrix that getOrbiterLocalToNavigationBaseTransformation() returns [19:07:22] some of this code feels like it is the way it is (especially wrt intrisic/extrinsic rotations) because of trial and error [19:07:43] yeah, sure does [19:07:49] so would be mine though [19:08:18] ...don't look too closly at my drift branch haha, sama method [19:08:21] *same [19:08:46] I think I would have an easier time if I was just forgetting the correct coordinate system for now [19:09:08] just convert GetRotationMatrix to right handed and go from there [19:09:13] that I know how to deal with [19:11:49] if I ever get a time machine, I'm going back to October 2000, London, and asking for some axes to be swapped... [19:13:28] right? Imagine if we could actually use the correct system [19:25:03] I blame the road system, probably makes things like this seem normal [19:25:40] as a left handed person I can also relate [19:29:13] at least we're mostly in R3 and only have to deal with one bijection [20:35:01] night! [03:22:35] .tell indy91 https://github.com/orbiternassp/NASSP/commit/62c958b745543df34d5c27ef9402c37964ede66d I pushed it to the wrong branch, can probably be cherry-picked [14:50:53] hey [15:07:52] hey Niklas [15:09:24] you could make this commit a PR really [15:10:07] well that was my intent, but I had uncommitted changes, and it was late [15:12:11] ah right, in case I need to use debugging. Thanks! [15:12:44] First thing I am looking at today with the Skylab coordinate system stuff, I got a matrix transposed [15:12:57] and it seems all the issues I had are gone :D [15:15:24] sometimes I spend like 5 hours hitting my head against a problem, and then come back the next day and fix it like 5 minutes [15:15:40] yeah that happens pretty often [15:22:20] I guess I will put in the other LVDC and FCC equations then. This initial Skylab attitude control will be heavily based on that [15:29:50] hmm in terms of attitude control, I will give the abilitiy to switch between different modes with a keyboard command. And when you do that display the current mode? [15:29:54] lacking any panel or VC... [15:30:48] I know a few addons like the Dragon have something permanently displayed on the HUD for that [15:30:52] yeah I'll do it like that [15:32:20] clbkDrawHUD [15:58:07] oh this looks interesting: https://ntrs.nasa.gov/citations/19700014945 [16:25:13] more for the Skylab folder :) [16:32:37] morning! [16:41:11] hey Mike [16:41:32] what's up? [16:55:27] hey [16:55:38] I think I figured out the worst of my issues with Skylab attitude stuff [16:56:17] nice! [16:59:34] I'm not implementing sun sensor and star tracker right now, which is used for that [16:59:47] although eventually we want those, for P50 and P55 in Skylark [17:42:58] I might take a bit more time on this VHF thing. I think starting with fixing the LM-CSM connector makes more sense [17:48:38] what I'm working on right now is very messy and it would be much easier to start with something that works [17:49:58] if it is actually less messy in the end then it's definitely worth it to take some time [17:50:43] you don't have to solve all related problems at once though, like needing the vessel name to know which vessel to connect to for e.g. VHF [18:45:21] don't worry, I won't turn it into one of my year-long projects :) [18:46:19] I just know that when I have changes in 8 files, and things still need to get more brokwn before they get less broken, that I'm on the wrong track [18:46:29] haha [18:47:05] speaking of year long projects, do you want to make the changes to start using the "new" mesh or should I give it a go, also looking at the animations etc.? [18:47:49] I can finish this attitude control project with the thrusters in the wrong place so that they visually look like. Shouldn't be a big issue with controllability [18:48:06] I can commit the new mesh tonight [18:48:26] also no guarantee that this mesh is exactly right [18:48:38] will have to see where the thruster effects appear... [18:49:09] if it's just a little bit off when I'd rather use the correct thruster locations and eventually fix the mesh [18:49:15] if it is more... not sure [18:49:24] then* [18:50:26] do you have a branch with thruster effects?\ [18:51:17] not yet [18:51:26] I can make one with my WIP [18:53:05] it would be pretty quick to check with the mesh, then [18:53:58] I know the mesh needs a little bit of a shift, but only in Orbiter's Z axis (skylab -X) [18:55:18] for a quick check I'll just try that myself I think [18:55:40] looking at my new code now, I'd rather not commit it yet haha [18:55:52] haha, fair enough [18:56:48] the coordinate system origin with no CG shift should be at the intersection of the docking-ports IIRC [18:56:52] yeah [18:57:18] I'm not far away though, I got the basics working now [18:57:56] awesome [19:01:42] you just press A to cycle through the attitude control modes [19:01:48] shows in the HUD which one is active [19:01:54] there is also a manual mode [19:02:04] strange, it works exactly like Saturn takeover mode :D [19:03:22] Orbiter default attitude control can't handle the 6 thruster setup [19:05:30]