[15:01:26] NASSP Logging has been started by n7275 [15:01:28] good morning! [15:14:15] hey [15:33:48] Orbiter Sound 5.0 is so annoying [15:34:04] it always opens some utility when you type outside of Orbiter [16:27:10] odd [16:27:24] I've never had that happen [16:29:49] it seems to recognize some key combination I am doing [16:29:56] when I am not tabbed into Orbiter [16:32:19] ctrl+shift+s ? [16:32:46] hmm [16:32:54] maybe I am accidentally doing that [16:33:14] I am doing CTRL+S very often in Visual Studio [16:36:21] yeah, I usually dont have orbiter open when I'm working in VS, so probably why I haven't seen it [16:36:56] it probably isnt paying attention to window focus which is annoying [16:37:29] yeah, the sounds are also playing when you are not looking at Orbiter, but I think that was the case with the old Orbiter Sound already [16:39:48] supposedly there is a setting for that [16:40:38] in the Sound Config? [16:41:01] advanced_congfig.cfg or advanced_sound_config.cfg or something like that [16:41:28] aha! [16:41:38] Editable_Advanced_Configuration [16:42:00] "default false" [16:42:04] now that's a lie :D [16:42:11] thanks for the tip [16:42:11] lol [16:44:19] or I did another weird keyboard combination to enable it haha [16:49:39] morning! [16:49:51] I'll check on mine later when I'm home. I'm curious. [16:49:58] morning mike! [16:51:16] trying a different strategy on 045? [16:51:43] nah, was just updating the tickets last night to reflect the current strategy [16:52:01] I need to make a nice cleaned up version of 044 before I try to get more people helping on 045 [16:54:59] hey [16:56:25] hey alex [16:56:49] ahh, okay [17:01:26] does anyone know off the top of their head if the logging functionality in SPSDK gets enabled by debug mode? [17:02:33] hey Mike and Alex [17:03:49] what logging functionality? [17:07:34] I probably misread something [17:07:37] ProjectApollo PanelSDK.log [17:07:38] ? [17:07:54] I think it gets enabled in debug mode [17:07:57] #ifdef _DEBUG [17:08:03] yeah [17:08:07] but I don't think it does real-time debugging [17:08:23] just when building the systems [17:08:32] ooooooh [17:08:57] FILE *debug; [17:09:13] that's where it puts any error messages, but I think it is only used in BUILD.CPP [17:09:30] I'll just fstream out some stuff then [17:10:32] need to make some temperature graphs [17:11:36] so I can make sure I'm not sending you guys any more bugs [17:13:07] yeah, same reason why I have to fly about 10 TLIs in the next few days... [17:13:38] or I could fix up all the launch scenarios and the code, fly 1 TLI and then outsource the work to Alex [17:14:27] theres a solution :) [17:15:51] I "fixed" the radiator class. miraculously, without breaking it probably [17:16:04] but I want to make damn sure [17:16:14] what did you fix? [17:16:34] it now knows about air and convective heat transfer [17:16:44] oh awesome [17:16:59] that is one big source of issues we had in the LM ECS [17:17:13] no more SetTemp functions needed [17:17:33] music to my ears, and to Ryan's as well [17:18:18] haven't tried with apollo 5 yet, but I will this weekend [17:18:47] Apollo 5 easily breaks, hopefully I didn't recently haha [17:19:16] on Apollo 5 I got mostly annoyed that the LM was heating up a lot before launch [17:20:28] the bath of GetAtmTemp() K air that its sitting in should hopefully fix that [17:22:21] nice :D [17:23:28] what I'm most worried about breaking is all the antennas and other things that aren't radiators per se, but that have an associated "radiator" class [17:23:58] rcs quads, etc [17:24:27] we have a fun feature, if the RCS quads get too cold they stop working [17:25:16] good way to test them, lol [17:25:51] right now it can really only happen if you disable the heaters and point the quad away from the sun for about 20 hours :D [17:38:55] ahh. well they probably wont get that cold sitting outside at whatever temperature orbiter thinks Florida is in July (25°C, lol) [17:42:40] yeah, sitting at the cape results in the opposite problem [19:47:59] man [19:48:10] I wonder if Comanche 45 is going to be obvious once we figure it out [19:48:17] or if it will be something completely arcane [20:03:20] yeah [20:03:27] I'll try a bit more in a bit [20:04:10] I realized something else last night [20:04:41] S40.1 and S40.1B are totally separate -- so in addition to moving the end of S40.1B+THETACON, we could also possibly move the end of S40.1 or the beginning of S40.1B [20:07:31] I think I tried the end of S40.1 [20:07:37] not the beginning os B [20:07:39] of* [20:08:10] one thing that got me "fairly" small errors was just moving THETACON to bank 17 [20:08:18] but small as in [20:08:26] bank 16 in the 1000s, 17 in the 100s or so [20:08:42] wait [20:08:46] that doesn't make sense [20:09:07] when did I get that... [20:09:51] well it probably wasn't any good anyway, can't remember what I did. But it was mostly moving THETACON [20:15:00] and about the 5 words, I guess there are a bunch of ways to make it 5 only [20:15:11] but in any case they would have to go out of their way to get that [20:15:17] and it's not like they were short [20:15:41] on memory [20:18:10] yeah [20:18:43] so probably the answer is a fairly natural way to get 5 words [20:18:46] and not a tricky one [20:19:18] I'll just assume for now that they put the three new words in the same location as it is later on [20:19:44] reduces the problem by one magnitude of variations :D [20:19:56] I think given the comments that are there I think that is the best assumption [20:20:10] because there wouldn't be any reason for them to talk about a module change in comments after rev 45 [20:20:30] what I next wanted to try (will in a bit) it to just have the jump someone in S40.1 where it is convenient [20:20:36] not right after the three new words [20:20:45] somewhere* [20:20:47] also I have been getting more and more annoyed about that DMPR change lol [20:21:04] such a silly little change, and it wiped out the asterisks that would have let us easily pinpoint this more complicated one [20:21:11] haha [20:21:20] well it's a good change if it makes you feel better [20:21:23] good for LOI-1 [20:21:26] precisio [20:21:27] n [20:21:37] not really :P [20:22:01] I'd rather be able to better reconstruct buggy software than be unable to figure out better ones lol [20:22:55] 3 ft/s error in velocity-to-be-gained for LOI-1 [20:23:30] in "pitch" basically [20:23:46] so the orbit just gets rotated a bit too much or too little [20:23:56] probably not that noticable on Apollo 8 yet [20:24:03] but probably on 10 with the LM [20:36:28] just imagine if we only had Comanche 44/45 and I had to work out docked LOI-1 burns in the RTCC with that [20:36:40] that error would have confused me [20:36:59] so for me the DMPR change is good :D [20:37:01] hehehe [20:37:19] I just wish it had been done prior to Apollo 10 :P [20:37:32] oh I can agree with that [20:38:40] guess nobody ever did the math of the central angle calculation by hand as a cross check [20:38:46] at least not before the anomaly was found [21:27:21] so we basically have to find places where adding a goto only adds one word [21:27:24] and that twice [21:27:29] if the 5 words are correct [21:27:52] already tried one, almost at the end of S40.1, but didn't work [21:35:12] if we jump there and back then yeah [21:35:30] or there's a way to jump only to bank 17 and then off to bank 24 or whatever without going back [21:35:35] right [21:35:40] there are some goto's [21:39:18] or there's some other obvious way to do this [21:39:38] don't let my ideas fully dictate whatever you want to try :D [21:40:08] I consider my lack of experience in this an advantage :D [21:40:15] haha yes absolutely [21:40:29] one more thing that I have been thinking is that the 22500 bank difference in bank 17 is a suspiciously round number [21:40:39] those 2 trailing zeroes may not be a coincidence [21:40:42] ...but they might be [21:41:53] what would that indicate though [21:42:30] no idea :D [21:56:17] does Norton use a listing for his document? [21:56:48] so how sure are we really that the three new lines didn't move after 45 [21:59:44] yes, he uses a listing [22:00:05] and without seeing the unrevised page for 45 there's no way to be 100% sure [22:00:11] but did he ever use a 45 listing... [22:00:12] but he's usually pretty good about marking moves like that [22:00:21] almost certainly yes [22:00:39] I don't think he could have made this without one [22:00:46] well [22:01:03] he may have never used a 45 listing, but he definitely used 45 rev 2 [22:01:33] and 45 rev 2 would still have the fix as in 45 [22:03:36] yeah [22:03:53] that's one thing I'm going to do tonight, make sure that the 45R2 changes are identical to 51->55 [22:38:20] well, tried a bunch of things, but no luck [22:38:37] back to 10666 and 22500 and try again another day [22:39:19] night! [16:09:35] good morning [16:12:48] hey Alex [16:15:43] about to fly Apollo 8 TLI again with my latest round of fixes [16:16:01] if you want you can help and fly some launches and TLIs soon, there is a lot of missions to test [16:29:27] sure [16:32:57] just want to fly Apollo 8 and 9 to the end of all their attitude maneuvers [16:33:11] then just some small fixes to all launch scenarios [16:33:20] and it will be ready to go for some testing [16:37:45] great [16:39:13] I had a lot of trouble combining what I know about the attitude maneuvers from the little sources we have and how to implement that [16:39:56] Apollo 14 LVOT for examples has the time to maneuver to TD&E attitude (TB7+900 seconds) in the Events Processor module of the LVDC [16:40:08] events processor is great to schedule things on time [16:40:19] but they had the capability to inhibit and delay that maneuver [16:40:32] and the events processor is not good at making things happen at variable times [16:41:38] and that also didn't work well with Apollo 9. The maneuver to TD&E attitude is done on a time since GRR, not timebase 5 [16:42:19] so I am kind of using a hybrid solution, some special code in orbital guidance that sets up events in the events processor [16:42:25] no idea how they actually solved this [16:43:26] but TB5 and TB7 maneuvers can now in theory be inhibited and rescheduled, just like in reality [16:43:47] useful for the case of TLI not happening and doing TD&E in Earth orbit [18:11:06] morning! [18:30:27] hey Mike [18:32:11] I realized yesterday looking at the gravity model module change that if we jump to bank 17 with CALL or STCALL, we can get back with just RVQ, which is either 1 or 0.5 words [18:32:21] which makes the 5 word requirement a bit easier to hit [18:33:10] interesting [18:33:38] if it's a call then bank 17 might as well have the DELVSAB calculation [18:33:54] plus extras [18:35:02] well the additional stuff that needs to be moved would make it not very clean, so maybe it's just some part of S40.1 or S40.1B that is put in a subroutine [18:41:54] does STORE save the return location? But in any case you probably have to be careful to not put a subroutine in a subroutine or otherwise mess up the return location [18:42:00] uhh [18:42:06] I meant CALL/STCALL [18:42:21] yeah [18:43:41] it also can't be the the chunk with the "STQ" in it because the CALL would stop that from working too haha [18:44:35] right, that's to make nested routines working [18:45:38] with CALL it wouldn't make sense to move the end of S40.1 or S40.1B, because that already has a goto [18:47:50] it could be a STCALL instead of the STORE DELVSAB for example [18:48:19] yep [18:50:30] and then move the next 4 lines and make it STORE RVQ, VINIT [18:50:43] guess there are a few variations like that [18:52:32] at least that would be a solution that adds 5 words naturally [18:52:39] and not trying really hard to make it only 5 [18:53:54] yeah for sure [18:54:42] makes more sense to me than the GOTO solutions [18:55:39] I'm going to be mad if it's not actually 5 words lol [18:55:56] do we know that we have the right number of words in 44? [18:55:59] nope [18:56:07] fun [18:56:20] the banksums are right, which means "probably" [18:56:45] I'd trust Comanche 44 [18:56:49] but I did have to do that weird thing to LDPLANET [18:56:53] except for maneuvers :D [18:57:00] hehehe [18:57:11] but it should at least have no problems working right [18:57:42] even with the LDPLANET solution [18:58:33] yeah it should work fine [18:59:16] getting confused with versions again, when was LDPLANET added? [18:59:44] and when did it have a fix applied to it or whatever [19:00:59] it was added between C249 and C44, and presumably changed between C44 and C51 [19:02:26] right [19:03:05] in any case, I don't think they even used an input star vector for P23 on Apollo 10 [19:03:55] although I haven't seen the full loss-of-comm P23 schedules [19:09:21] that feature was new on Apollo 10 [19:09:36] that's why it doesn't appear in the Apollo 8 checklists :D [19:09:43] haha yep [19:09:49] PCR 682 [19:12:18] bye bye S-IVB-503 [19:12:30] all you have left to do is one more attitude maneuver and I am happy with you [19:14:52] although they tend to call it 503N. Not sure what the N means [19:15:18] oh [19:15:27] there was a 503 that was destroyed during testing [19:15:37] and then there were 503N, 504N, 505N [19:15:44] and then 506 etc. for the rest of the S-IVBs [19:16:37] "Following the loss of the S-IVB-503 stage during testing on January 20, NASA officials amended identification numbers of subsequent S-IVB stages to fill the vacancy created. The S-IVB-504 became the S-IVB-503N, S-IVB-505 became S-IVB-504N, and S-IVB-506 became S-IVB-505N. A replacement stage using an old S-IVB-507 tankage became S-IVB-506, and S-IVB-507 and subsequent stages retained the old identification. (The "N" [19:16:38] at the end of the stage identification stands for the word "New," a designation that became necessary after an earlier stage version exploded, necessitating the use of a substitute stage.)" [19:33:57] hahahaha [19:34:01] not confusing at all [19:38:16] speaking of confusing, the attitude maneuver I was anticipating was barely noticable [19:38:33] "Due to the initial alignment of the vehicle at the start of this [19:38:34] maneuver, less than a 2-deqree change in pitch attitude was required" [19:38:46] got me concerned for a moment :D [19:39:25] hahaha [20:14:50] Hey [20:14:56] yo [20:15:12] What's up? [20:15:54] cleaning up Comanceh 44, you? [20:16:19] Trying to get my Xilinx programmer working [20:16:49] Drivers won't compile, and documentation is pretty much non existant [20:18:14] compile? I'm used to getting binary blobs haha [20:18:18] what programmer? [20:19:03] platform cable USB II [20:19:14] DLC9LP [20:19:37] hey Thymo [20:19:49] hmm, haven't used that one [20:19:52] These drivers are shipped with the Xilinx ISE [20:20:03] oh jeez, ISE [20:20:07] Yes [20:20:13] I have never had any experiences remotely positive with ISE lol [20:20:37] I have never had a positive experience with ANY proprietary vendor IDE [20:21:15] Vivado isn't bad [20:21:24] definitely a huge step up over ISE [20:23:34] Too bad this is the only supported way to get this adapter updated. They just ship an ISE project for you to flash the update with [20:23:53] Boy am I glad the update implements a self-update capability [20:24:12] Heh [20:24:18] I think I got it [20:24:26] Used an opensource alternative based on libusb [20:24:41] At least it doesn't complain about windrvr6 not being loaded [20:32:30] It sees the programmer now. Had to unbind the ftdi drivers from the programmer [20:32:53] It complains about an idcode in a bsdl file though, no idea what that means [20:33:33] me neither [21:08:25] Firmware isn't loading as the device shows up as a different id as the supplied udev rules [22:07:15] I have now spent almost the entire day tuning EPS radiator temperature performance...its getting closer maybe one more day [22:08:51] haha nice! [22:15:59] awesome [22:16:04] good night! [23:36:08] thewonderidiot: Is Vivado backwards compatible with iMPACT at all? [23:36:27] As in, will it read the project files? [23:36:28] unfortunately I don't know what iMPACT is, so I can't answer [23:36:56] Part of ISE [04:12:33] alright, well I've confirmed that the comanche 51 -> 55 changes, when applied to comanche 44, make the module B2 checksums exactly match 45 rev 2 [04:12:39] so it really is just this one anomaly fix [04:19:35] Awesome news, Mike. [05:16:39] .tell indy91 hey, do you know what this was for https://github.com/n7275/NASSP/blame/425e30f22e710cb004ec03ff85dfc4c35a3fb34c/Orbitersdk/samples/ProjectApollo/src_sys/PanelSDK/Internals/Thermal.cpp#L40 [06:33:12] lol I just had a brief moment of "wait I'm a software engineer, why am I manually brute forcing this" [06:33:34] gonna try to write a script that looks at all possible groups of 4 words with an RVQ following to see if any have the correct sum by themselves... [08:04:15] no hits :D [08:04:19] so that's not it lol [09:08:35] worth a try though [09:12:32] n7275, that's for stability reasons. Hopefully never happens, but if it wants to remove more energy from a thermal object than it has, it is only allowed to remove 10% of the energy. [09:13:41] not a good way of doing things, but as you said before, doing thing one timestep at a time (so like an Euler scheme) causes some problems with mass and energy flow [09:13:51] things* [09:14:06] ahh, makes sense. [09:14:22] at least we are not getting NaN anymore [09:14:40] we've had a lot of trouble with that in the LM ECS [09:16:24] with any luck I won't need to dig into anything LEM related during this fuel cell project [09:17:14] but you are changing how radiators work, right? [09:17:21] That of course affects the LM as well [09:19:53] correct [09:23:17] all I'd really added was a line to warm radiators up to ambient air temperature at ~20W/(m^2K), linearly proportional to density so NRLMSISE-90 doesn't cook it [09:23:49] ah ok [09:24:00] what does that do in space? [09:25:34] in lunar orbit/cislunar space there's (double)0.0 heat transfer from convection [09:26:04] that tells me it won't break anything and might just help out Apollo 5, great [09:27:29] on the LM side of things [09:30:09] hmm, did we lose the Apollo 5 -1hr scenerio? I don't have it in my branch [09:30:53] that's with the WIP scenarios [09:31:06] where we also have Apollo 12-17 [09:31:19] I swear I can read... [09:31:55] I wont admit how long I'v been looking for that, lol [09:32:06] oh no, haha [09:32:14] "The scenario starts on the pad at T-1min40s." well that's a lie [09:37:03] that's from the scenario description, probably was never changed from our very old previous Apollo 5 scenario [09:42:33] I seem to remember an Apollo 5 incarnation from the early 7.0 days [09:43:02] this one's way more fun [09:46:28] speeking of old code: this thing still drives https://drive.google.com/open?id=1EIEkyGCW8jam8pmF4V7V6dYy38RCtEOL [09:47:42] yeah, you can move the Saturn V from the VAB to the pad [09:47:59] still worked when I last did a round of fixes for it [09:48:27] SSU has a better crawler though [09:48:40] oh that's cool [09:49:01] could have to do with the fact that about 0 work has been done on our crawler in the last 15 years [09:49:18] maybe, lol [09:51:29] I'm sure we'll get there, I'm not in a huge hurry to add these radiators to it yet though :D [09:51:49] haha [09:52:16] the only other vehicles we have that use the systems SDK are the S-IVB and the LRV [09:52:28] S-IVB has a single battery right now, not used for anything [09:52:56] the IU has an ECS as well, maybe some day we can simulate it [09:57:14] less things to worry about breaking right now and a good opportunity to fix any issues we have with the SDK before we do add them [09:57:45] yeah, definitely [11:36:40] uh oh [11:55:48] .tell n7275 just tried to launch Apollo 9, my fuel cells shut down after their temperature wasn't artificially kept up anymore [12:35:36] oh that's bad [12:35:45] hmm [12:35:56] just tried a fix, but I am no longer convinced that is the case [12:36:01] power is definitely lost [12:36:07] and then the crew dies, overheating maybe [12:36:30] happens at about T-30 minutes [12:36:44] I used the Apollo 9 MCC scenario if you want to test [12:37:05] and I just had merged your latest update, so I am quite sure it's caused by that [12:37:36] what I thought it was at first was this: this->systemsState < SATSYSTEMS_GSECONNECTED_1 [12:37:44] for the FC temps [12:38:06] that stops at T-1h40m I think, while GSE power isn't stopped until T-15 minutes [12:38:24] strange that It didn't happen on the apollo 8 scenario [12:38:38] I'll test the others [12:38:39] maybe temperature related? Different lighting? Not sure [12:38:47] try Apollo 9, works reliably [12:39:16] a lot of meters are doing weird things, but I think that is a separate bug for when power is lost [12:39:55] FUELCELL1 0 0.0000000004 475.0000 0.0000 0.0000000005 [12:39:56] FUELCELL2 0 0.0056666612 475.0000 0.0000 0.0074956237 [12:39:56] FUELCELL3 0 0.0000000004 475.0000 0.0000 0.0000000005 [12:40:02] I think this looks normal [12:40:59] definitely running, status is 0 [12:41:30] batteries weren't used [12:43:16] hmmm [12:43:26] I am using auto checklist execution [12:43:36] I wonder if the checklist is bad [12:43:50] but I'm sure we would have noticed before [12:44:11] and can you even disable GSE power... [12:52:04] very strange [12:58:05] I'm getting NaN voltage from the fuel cells [12:59:15] maybe that's the issue [13:02:25] oooh [13:02:31] might have found something [13:02:38] 0 power load might be bad for the FCs [13:02:51] reactant = dt * max_power * thrust / 2880.0 * 0.2894 ; [13:03:01] reaction = (H2_flow + O2_flow) / reactant; [13:03:09] divide by 0 maybe? [13:05:08] yep, that's it [13:06:07] reaction becomes NaN [13:06:13] because reactant is 0 [13:07:43] I'll put in a temporary fix, you can revisit it properly [13:07:49] that would make sense [13:09:02] basically the solution we had before with the 160W to keep it running [13:09:29] yep [13:10:11] but 1W is enough [13:10:16] just has to not be divide by 0 [13:10:36] and was your intention to keep the FC temps up until GSE power is disabled? [13:10:55] because I think you stopped the SetTemp one systemsState too early [13:12:34] although I will test that [13:37:53] n7275, still here? [13:47:35] yeah [13:48:16] maybe just keep settemp on a little longer then [13:50:16] I'm genuinely confused about how I made it so far in apollo 8 [13:50:47] probably the lighting, like you said, I guess [14:05:11] actually, I discovered something else [14:05:18] sorry, was away for lunch [14:05:39] the way systemsState is progressing is a bit weird [14:05:53] scdp = (atm.SuitReturnPressurePSI - atm.CabinPressurePSI) * (INH2O / PSI); [14:05:54] if ((scdp > 0.0 && MissionTime - lastSystemsMissionTime >= 50) || MissionTime >= -900) { // Suit Cabin delta p is equalized [14:06:03] that just never happens [14:06:33] suit/cabin DP for me is -28.9 or so, but that is a bit of a weird unit [14:06:42] well that's odd [14:06:55] so it doesn't progress at the time I was expecting [14:07:04] but as you can see there, at T-900 seconds it forces it to progress [14:07:20] so the SetTemp didn't cause any problem [14:07:31] as it was still doing its thing until T-900 seconds anyway [14:08:05] but that might all be as we had it before. Probably should be revisited some time, but not causing bugs [14:09:43] but with the FC bug, there has to be some weird condition that becomes true at about T-30 minutes that it even checks the fuel cell voltage [14:10:11] I seem to have a fuel cell powerload at T-1 hour which I find weird [14:11:30] main bus controllers have a NWayPowerMerge [14:11:48]