[16:52:38] NASSP Logging has been started by indy91 [16:52:45] https://i.imgur.com/Az8P6Dh.png [16:57:27] hey [17:00:29] hey [17:00:41] picture above shows your new gain calculation [17:00:44] is that how you want it? [17:06:20] yeah, I think that's reasonable. [17:07:05] good [17:09:41] of course with those gains I had no problem with VHF ranging for either antenna [17:11:59] yeah, I'm getting reasonable signal strength now. and not forgetting to tmul, by the rotational matrix is giving much more predictable results [17:14:13] tried out Thespacer's latest sceneriao and ranging wasn't working still. [17:14:14] I have some notes, but nothing major [17:14:39] but I hadn't looked to far into why yet [17:14:43] worked fine for me [17:15:10] I'll try it again. that's odd [17:15:17] your gain equation [17:15:18] gain = sin(1.4562266550955*theta [17:15:19] etc [17:15:24] the sin term is twice [17:15:33] so probably better do a pow(x,2) [17:15:37] x being the sin term [17:15:47] I guess this code is from the omni antennas [17:15:50] should be done there as well [17:16:12] and then a wrong comment [17:16:13] MATRIX3 Rot; //rotational matrix for transforming from global to local coordinate systems [17:16:20] that matrix is from local to global [17:16:33] that's why we need to use tmul not mul [17:16:44] ahh darn. yep. thanks [17:17:06] where is the scenario that didn't work? [17:17:16] in which forum thread [17:18:33] the last post with an attachment https://www.orbiter-forum.com/threads/csm-vhf-ranging.39595/ [17:18:57] I'm away from my computer at the moment, but I'll look at more when I get back [17:21:45] ok [17:21:51] I'll check the scenario with your branch [18:10:25] okay, back [18:14:27] ok this is weird [18:15:46] I was afk even longer haha [18:15:56] starting that scenario now [18:16:30] Orbiter is randomly not shutting down completely... [18:16:53] I have immediately VHF ranging in that scenario from thespacer [18:17:06] hmm, try rebuilding. I have something like that occasionally as well [18:17:31] rebuilding now [18:18:05] its weird. it let me launch with 2 other Orbiter process running... [18:19:22] all the textures were z-fighting, and the CSM was the only vessel in the sceneriao...but VHF ranging still worked [18:34:25] I have to check again, but one possible issue I got was VHF ranging continuing to work if I switch the LM to a comm configuration that should definitely not work [18:34:47] but I have to try that again, might have misunderstood what I did there [19:50:42] morning! [19:54:01] hey [19:58:05] how goes VHF? [19:59:22] good when the gains are high and the coordinate system transformations are done at all :D [20:00:37] speaking of coordinates [20:00:45] n7275, in OMNI::TimeStep there is [20:00:50] U_RP = _V(direction.y, -direction.z, direction.x); [20:01:29] if you delete that then you can use the Orbiter coordinates in the Saturn constructor for the omnis [20:02:42] better to be consistent between omnis, VHF antennas etc. [20:04:36] yes, I'd already added some reminder comments on them. wanted to do it in a seperate commit [20:05:59] makes sense [20:33:04] okay fixed and pushed [20:35:03] I'm going to double check that LM comms thing, unless you already found the issue? [20:38:08] which one, VHF ranging still working despite LM in the wrong comm config? [20:38:50] didn't get to testing that yet [20:38:56] have some bugs of my own.. [20:41:43] I turned the recievers and transmitters off in the LM and it still works, so theres definitely a problem [20:55:06] maybe a case where no signal gets sent from the LM to the CSM anymore? [20:55:17] and the code interprets that as, nothing has changed, everything fine [20:57:01] yeah, probably need to set everything to zero at the end of the timestep [20:57:27] I guess it needs a good connection on every timestep [20:57:35] also the CSM never checks for a range tone back from the LEM, even though its sending it(when it should at least) [21:03:29] well that appears to have fixed the problem [21:07:18] bet the LEM has the same problem [21:07:28] it does [21:08:03] my bug was luckily easy to find [21:08:07] but I found it in debug mode [21:08:34] and sometimes API calls in debug mode to other modules (like the Saturn vessel) don't work right [21:08:49] S-IVB weight of -890,000 kg isn't good, right? [21:09:20] oh that's very bad [21:09:34] the total mass of the vehicle was above 0 though, which made that a bit more difficult to find [21:09:44] the TLI simulation threw the error, below a certain mass threshold [21:09:53] of course all I had to do was build in release mode haha [21:11:45] I let the MCC use the mission plan table with all its advanced RTCC features now [21:11:47] but only for TLI [21:12:07] it gives consistently long burn times though [21:12:09] 2-3 seconds [21:12:21] have to check the RTCC system parameters for thrust and specific impulse [21:14:27] speaking of system parameters, I think the JSC History Collection has some of those [21:14:41] a document with RTCC system parameters for Apollo 7 [21:14:51] but then also [21:15:24] "Oversize - Stored on Shelves" [21:15:38] "Apollo and ASTP Real - Time Program [21:15:39] System Parameters (computer [21:15:39] printout)" [21:15:45] 1968 - 1974 [21:15:51] hmm [21:16:47] the RTCC even had TLI targeting parameters stored, so best case would be that it has numbers for all missions for TLI, the numbers we only have for Apollo 8, 11 and 14 right now [21:17:16] have to ask some time about them. What format, can they be scanned etc. [21:17:56] but probably not. There is a difference between system parameters and stuff stored in tables [21:19:00] the TLI parameters are split between tables and system parameters, system parameters wouldn't have everything but still useful [21:19:43] hey, I had a question about landing sites and delta V [21:19:54] sure [21:20:04] and you're probably the best person to ask [21:22:08] how far North or South could you realisticially land, and is the latitude limit a constant band around the moon, or lower at the 90E and 90W positions? [21:26:26] hmm [21:28:39] one limiting factor in the lunar declination [21:29:29] you will always have a plane change during TLI if you want to go to higher latitudes than the lunar declination normally allows [21:30:03] but that assumes the standard one or two maneuver lunar insertion [21:30:34] Jack Schmitt really wanted to go to either the lunar backside or Tycho crater [21:30:41] Tycho crater is at a high latitude [21:30:58] most studies involving that landing site would have done a different lunar insertion technique [21:31:11] LOI-1 with any plane change, but a very high apolune [21:31:19] then a plane change at apolune [21:31:22] without any* [21:31:40] high apolune, low velocity, small DV necessary for the plane change [21:31:49] and then a circularization maneuver as the third LOI maneuver [21:32:21] much more efficient like that, I imagine [21:32:30] yeah [21:32:37] Tycho is pretty far South [21:32:47] I've gone there to land with Zerlina [21:32:59] but I didn't have enough DV left for TEI haha [21:33:46] yeah, I think I've seen your video of that [21:34:19] the latitude band used for the early mission (I think +5° to -5°?) was partially caused by free return [21:34:35] free return will have pericynthion close to 180° longitude [21:34:48] non-free return not so much [21:36:30] so pericnythion close to 180° (latitude could be quite high there) means lunar equator crossings near 90E and 90W [21:36:49] so yes, it's probably more difficult to reach high latitudes at 90°E/W [21:41:46] yeah the initial Apollo landing zone was 5°N to 5°S and 45°W to 45°E [21:43:19] that makes sense [21:47:59] Apollo 15-17 landing sites would be quite difficult to reach with free return [21:48:57] possible though [21:49:05] Apollo 17 alternate mission where LM ejection doesn't work [21:49:36] they would have done a 600 ft/s MCC-1 maneuver to get back to to free return and still reach the landing site [21:49:45] to at least fly over it [21:55:26] I think I have a weird race-condition between the VHF timestep functions and ReceiveMessage now... [21:58:10] if zeroing at the begining of the timestep doesnt work, I wonder if it needs to be in clbkPostStep [21:59:08] doesn't sound fun [22:07:20] no [22:15:11] If I had any hair left, I'd be pulling it out now [22:23:14] maybe start from the CSM and try to retrace all the steps a signal is going [22:23:32] I wonder what would happen in reality in such a wrong config though [22:23:45] maybe some headset destroying feedback :D [22:25:31] I assume Orbiter calls clbkPreStep() for each vessel in the order that they're loaded from the sceneriao file [22:27:22] yeah, I think that is correct [22:27:27] the issue is the ReceiveMessage function that the connector calls [22:28:10] because the CSM updates first, it has the values that the LEM sent, last timestep [22:31:58] yeah we definitely can't have a solution where it depends on the order in the scenario [22:33:30] we'll figure something out. Good night! [00:20:34] man [00:20:42] I am completely stumped on the Luminary 99 bug still [01:44:13] oooooooohhhhh actually I may have found something [01:44:41] oh? [01:45:28] so the two things we know about LNY-77 are "No takeover when Abort from P60's" and "software restart can cause up to 163 sec activity delay" [01:45:54] and I just found this snapshot I took: https://photos.app.goo.gl/RnveQtsEJFgCwtmj9 [01:52:21] oh that's interesting [01:52:31] that sure sounds like it :D [01:52:57] that gives me something specific to study, and that is not where I was looking lol [01:53:01] yes it does [01:53:12] so now it's just, why... [02:48:36] .tell indy91, fixed it. ended up being super easy. im just sending zeros using the sendRF function. no more race condition. I did something similar with the RR transponder [02:49:28] Guenter? you okay