[16:40:47] NASSP Logging has been started by indy91 [16:40:49] n7275, can't get VHF ranging to work [16:43:30] LM receiver A power is -nan(inf) [16:45:15] ah only in the wrong config [16:45:28] receiver B is getting -66 dBm [16:45:30] should be enough [16:48:45] so I think the LM is sending something back to the CSM [16:51:55] aha [16:52:00] I used the wrong VHF antenna [17:12:14] wrong antenna is what I figured [17:13:57] I used the one the checklist MFD told me to use, but I have to check if that's an error [17:14:03] and I'll look into that NaN [17:14:44] yeah that's an odd one. [17:15:19] I'll have to look into antenna directions too [17:15:37] yeah [17:15:42] I think I worked them out [17:15:50] probably correct, but wouldn't hurt to check [17:15:57] the problem might also be antenna patterns [17:20:07] it was a huge difference in dBm between the antennas [17:20:13] -60 to -200 or so [17:22:24] can't replicate the NaN [17:22:29] -200 is a little low. probably wouldn't be that bad even if it was inside the lem, lol [17:22:58] weird [17:25:29] oh wait I did the debug string in the CSM not LM [17:25:34] the code looks so similar :D [17:26:24] ok got the nan again [17:26:33] I wonder... [17:26:53] is it possible that CSM and LM are doing like a circular thing with the signal? [17:27:13] if the switch configuration is wrong [17:29:48] I suppose it's possible [17:30:06] looking at it now [17:30:51] RFCALC_rcvdPower(double xmitrPower, double xmitrGain, double rcvrGain, double frequency, double distance) [17:30:59] in this function calls frequency is 0 [17:31:04] function call* [17:31:12] the function does C0/frequency [17:31:17] and that is the origin of the NaN [17:31:55] yep [17:31:58] damn [17:32:02] missed that one [17:34:08] I think frequency was just a const in the code, before I added RF_calc.h [17:34:10] 0 by default and only gets set to a number if it receives something from the CSM [17:34:28] RCVDfreqRCVR_A in that case [17:34:31] in the LM [17:34:56] not a terrible bug as it doesn't prevent it wrong working [17:35:03] it's only NaN in a non-working config [17:36:04] ...which is also why I missed it [17:36:55] I only saw it because in the saved scenario I wasn't in the right config yet [17:37:14] well, better to fix and find now, than when we're trying to use the VHF systems for stuff later [17:37:15] and you said -200 dBm is also not good, right? [17:37:35] guess I'll trace that from CSM transmission on [17:39:41] yeah, the thermal noise from the antenna in an empty universe would probably be somewhere around -140 -- -150 ish [17:42:04] I think I used the same polar for CSM and LEM VHF antennas [17:49:35] "probably a toroidal polar, but this is close enough for now" [17:50:07] Is it, Matt, is it close enough?... [17:50:25] hmm [17:50:27] VHFAntenna::getPolarGain [17:50:33] I'm not sure that function is working right [17:55:16] I'd have to look at relative angles again, but It may need to be called with -R, rather than R [17:56:20] gain = pow(cos(theta / 10.0), 2.0)*maxGain; [17:56:25] this is what I am doubting [17:56:32] not quite sure yet [18:04:49] I think I intended it to look something like this: https://www.wolframalpha.com/input/?i=polar+cos%5E2%28theta%2F10%29+from+-90+to+90+deg [18:14:13] Given that it's a cloverleaf antenna with a large ground plane, it should probably look something like this though https://www.wolframalpha.com/input/?i=polar+sin%5E2%28theta*1.1%29+from+-100+to+100+deg [18:15:43] which would make sense with the antenna axies are orthogonal to one another not pointing in opposite directions like the CSM VHF [18:19:15] Hey Thespacer [18:19:47] Hey! Seems I arrived while my favorite topic is being discussed:P [18:21:02] I would say so. [18:21:35] Anything I can do to assist? I cannot code but I can test. [18:22:33] Indy91 is flying apollo 10 at the moment, and has had a chance to do some testing before I did. [18:23:06] Ah [18:23:18] At the moment, I think it might be the antenna gain patterns, but we're not sure yet [18:24:45] Ok, thanks for the update, I’m sure you’ll be able to get to the bottom of it [18:29:53] Hey thanks for helping out some of the new folks on the forum, btw. That goes a long way toward promoting and growing the project. [18:31:51] hey Thespacer, I agree, thanks for helping people, lowers our workload a bit [18:32:06] also, in doubt, switch to the other VHF antenna to get VHF ranging to work :D [18:32:23] but there is definitely something up with the antenna patterns, currently looking into that [18:34:51] Thanks guys - I figured I’ve quietly been stacking knowledge over a long period of time through my own research that it’s time to help others navigate the path, and if that means you’re free to keep doing your thing, that’s a double-win in my book. I myself have limited time and skills, but I was pondering some sort of FAQ for the AGC. I [18:34:51] know that’s been contemplated in the past. Regardless I figure if we can make the forums seem sufficiently active and encourage questions, then that can only assist the project. [18:35:58] Indy - when you say switch to the other VHF antenna, you mean in the CSM? [18:36:33] yeah [18:37:20] n7275, I'm sorry to say, but that CSM VHF antenna direction code is full of problems [18:37:51] the two vectors that it is calculating the angle between aren't even in the same coordinate system [18:38:58] pointingVector is in CSM body coordinates [18:39:24] the direction to the LM is in global (ecliptic) coordinates [18:39:46] that's why the omni antenna code has to do a conversion there [18:40:18] because we have like 7 antennas now in the CSM that need the direction of the Earth, it's probably the best if that only gets calculated once [18:40:22] in CSM body coordinates [18:40:42] and then the HGA, omni and VHF antenna code just needs to calculate the angles between the vectors [18:44:07] well, back to bugfix mode, then [18:44:53] yeah, all those checks for where earth is, probably account for quote a few function calls [18:51:46] ok, I still don't understand what you want to do with getPolarGain [18:52:05] if theta is 0° then the gain is -9 [18:52:24] but the function doesn't behave like you think [18:52:37] at 90° it has -8.779 or so [18:52:40] not -150 [18:52:49] so it even goes up [18:54:56] it doesn't give the behavior of that polar plot you posted [18:58:16] I guess it will roughly work if that factor "/10" is adjusted correctly [18:58:23] that's how the HGA code does it [18:58:41] and the function for the omni antennas you implemeneted probably also works fine [18:59:15] const double maxGain = -9.0; //dB [18:59:27] and this only scales the gain correctly at 0° [19:00:20] how about this, I'll implement that function (or class rather) that calculates the direction of the Earth and if it is occulted by the Moon [19:00:24] and you fix the rest? :D [19:00:56] that will simplify the HGA, omni and VHF antenna classes [19:02:31] uhh [19:02:34] dumb me [19:02:42] how would it help the VHF antennas [19:02:43] not [19:02:45] it doesn't :D [19:02:55] unless the LM sits at the center of the Earth [19:03:21] morning! [19:09:39] hey Mike [19:12:12] what's up? [19:18:09] debugging VHF ranging [19:23:20] n7275, I have a simple solution for pattern [19:24:22] okay [19:24:47] https://i.imgur.com/YGbynGO.gif [19:24:55] it's basically cos(x)² [19:25:10] and then mapped to -150 to -9 for the gain [19:25:17] x = cos(theta)^2; [19:25:18] gain = 141*x-150; [19:25:35] so that gives -9 in the 0° theta case [19:25:39] and -150 for 90° [19:26:06] oh that's much nicer [19:26:24] definitely simple haha [19:26:52] different question [19:26:53] in VHFAMTransceiver [19:27:08] you calculate [19:27:09] oapiGetRelativePos(lem->GetHandle(), sat->GetHandle(), &R); //vector to the LM [19:27:12] fairly early on [19:27:27] gets used in the receiver code [19:27:42] but for the transmitter code you do it again [19:27:44] oapiGetRelativePos(sat->GetHandle(), lem->GetHandle(), &U_R); //vector to the LM [19:28:14] any particular reason or an oversight? [19:28:58] and for the coordinate system issue [19:29:01] you need [19:29:02] sat->GetRotationMatrix(Rot); [19:29:29] R_body = tmul(Rot,R); would work [19:29:43] definitely an oversight [19:29:45] R_Body can then be used in getPolarGain [19:29:49] no need to get that twice [19:30:05] getPolarGain already does a unit on that vector [19:30:14] so no need for [19:30:14] U_R = unit(U_R); //normalize it [19:31:52] not sure why I forgot to change coordinate systems. looks like I did it right for the RR transponder [19:33:04] lol basically every class in the csm_telecom file has a different method for calculating the gain [19:33:17] consistent in its inconsistency! [19:33:25] back in a bit [19:34:58] yeah, that was why I added the RF_calc file. trying to put some of this boilerplate in one place and make it all the same [19:53:27] makes sense [19:53:52] so are you taking care of fixing all this stuff? I can help out if you want to focus on fuel cells [20:07:47] I'd rather go back and fix my mistakes. Fuel cells can wait. [20:09:00] sure [20:09:20] currently testing these rudimentary fixes [20:12:58] uhh [20:13:21] the direction vector is indeed in body coordinates [20:13:28] but not in the Orbiter left-handedone [20:13:36] left-handed one* [20:13:48] vhfAntRight(_V(0.0, 0.7716246, 0.63607822)), [20:13:49] vhfAntLeft(_V(0.0, -0.7716246, -0.63607822)), [20:14:00] those are in the standard, right-handed CSM coordinate system [20:14:16] might be easier to use left-handed, Orbiter coordinates for everything [20:14:22] then we don't need to convert [20:22:13] that would be [20:22:13] vhfAntRight(_V(0.7716246, -0.63607822, 0.0)), [20:22:14] vhfAntLeft(_V(-0.7716246, 0.63607822, 0.0)), [20:22:32] also, I don't think the antenna pattern will do [20:25:01] well [20:25:10] the directions there are pointing to the side [20:25:29] not forwards or backwards at all [20:26:08] so in normal tracking attitude the antennas will be pointing too far away from the LM [20:26:31] 65° and 115° in my case, even 65° doesn't give enough gain for VHF ranging to work [20:28:36] yeah that's the other thing I need to fix [20:29:00] csm vhf gain polar should be roughly hemispherical [20:29:12] lem polar should be like a doughnut [20:29:39] similar to how I did the sband omnis on the csm [20:33:05] so 90° for one of the cloverleaf antennas should be fairly close to maximum gain. the only thing that complicates that pattern is the ground plane pushing it up [20:36:00] I bet the scimitar antennas in the csm have more gain to the sides [20:36:39] CSM Data Book has the patterns [20:38:04] oh good. [20:38:26] HSI-41539 [20:38:34] PDF page 654 [20:38:47] to 661 [20:48:31] the VHF antenna selection is mentioned so little in any checklist [20:48:40] I doubt it matters much which is being used [21:07:42] ha, I even had that document open already [21:10:58] yep, so by the looks of it both the CSM and LEM VHF antennas are at least somewhat toroidal [21:20:51] okay, new branch. rebuilding. hopefully I can get this done tonight... [21:24:04] you are allowed to use very crude methods for testing [21:24:39] to test the code for the VHF antenna pointing direction I put the CSM in SCS mode and rotated it into gimbal lock [21:24:48] to point the antenna straight at the LM [21:48:32] I have a debug string from the RR transponder that prints theta-phi values that I'll probably steal for this too. [22:01:58] night! [05:40:51] .tell indy91 I've probably missed something that will only become evident with fresh eyes in the morning, but here's what I have so far https://github.com/n7275/NASSP/tree/VHF_antenna_fix [05:46:46] .tell indy91 haven't been able to find gain data on the LEM's antennas yet. if you know of document that might have this, also I could use a double check on my LEM antenna directions