[07:04:44] NASSP Logging has been started by thewonderidiot [16:20:10] morning! [16:42:28] hey Mike [16:46:52] what's up? [16:50:28] I think I was a bit optimistic about getting to the rendezvous day again today [16:50:52] heh [16:52:04] but I'll probably get to the end of EVA day, whichs means starting rendezvous tomorrow [16:59:34] excellent [17:25:02] I wonder if I got the EVA REFSMMAT for the CMC right this time [17:25:35] last time I flew Apollo 9 I had it completely wrong. I fixed it and probably tested it, but not from a much earlier scenario. [17:26:16] I think Alex and Ryan had me working on it until the visuals matched the photos from the actual mission :D [17:26:39] hahaha awesome [17:37:52] I didn't make any progress on Sundial last night [17:37:59] I intended to, but then unproductive things happened instead [17:43:08] those tend to happen sometimes [17:46:37] will try to finish bank 1 tonight [17:51:58] and then it's straight into pinball in bank 4, haha [17:52:54] and bank 5 [17:53:00] bank 6 is where the interesting stuff will start [18:03:21] in Sundance Pinball already gave hints to interesting stuff [18:04:13] probably won't be the case for Sundial, although I do want to make sure I do the extended verbs table before getting too deep into other things [18:04:28] so I know which ebanks they run with [18:05:03] ok, time for EVA [21:04:06] night! [16:50:13] hi [16:53:36] good evening [16:57:25] how's it going? [17:00:10] very well, just starting the Apollo 9 rendezvous day [17:01:29] making some progress with the transponder? [17:02:48] made a little bit. didn't haven't had much time the past few days. [17:03:24] it's a glorified power draw at the moment [17:03:44] haha, the start of many systems in NASSP [17:03:55] hi [17:03:59] hey Jordan [17:04:42] if i make a few classes a little friendlier, I'm just going to have to set a calendar reminder for "having a better solution" in like a year... [17:05:48] the most common solution we use to avoid that is an Init function that tells the system about any connected systems [17:06:49] that way you don't need any friend class, but just have pointers to the connected systems [17:09:31] morning! [17:09:53] hey [17:12:38] ah great, random CTD out of nowhere... [17:13:08] I might have pressed two keys at once, but how that would be a cause for that, no idea [17:15:15] I'll try the init thing, makes sense [17:24:40] might have been the Block Data PAD being displayed that caused the crash [17:25:06] I really should replace all the sprintf with sprintf_s to display the MCC display bugs that are surely there [17:58:27] Jordan64, just saw your ML textures on the forum. that looks awesome! [18:12:44] yeah, looks great [18:22:26] Thanks, still being worked on. [18:43:26] I have a few things to say about Sundance for the Orbiter Forum, could be a longer text, I better start writing soon :D [18:43:35] hahaha [18:48:53] I guess I can release it by the end of the weekend [18:49:08] excellent :D [18:51:54] and as I don't expect you have a new reconstructed Colossus or Luminary version by then, I can probably work on other stuff and try to find more bugs [18:52:09] nope definitely not [19:24:39] starting to activate the PGNS again, progress will be slower from now on as I have to do more checklist changes [19:54:22] nice! yeah that makes sense, heh [20:41:29] night! [05:08:28] hmm [05:10:54] hmm? [13:03:40] morning [13:52:12] hey mike. fell asleep before I saw your reply. [17:17:15] morning! [18:20:27] hey, I'm back... [18:21:36] hey [18:24:16] I have the worst internet connection.... [18:24:33] dont move to Maine if you can avoid it [18:24:39] heh [14:57:48] hi [15:10:53] hey [15:13:25] question, is the proper way to wire up circuit breaker: cbName->wireTo(&busName) ? [15:14:19] in the satsystems init function, of course [15:14:32] *systemsinit [15:22:46] no I think you want that in saturnpanel [15:23:32] Saturn::SetSwitches in saturnpanel [15:23:36] find your circuit breaker there [15:26:20] which circuit breaker is it? [15:28:48] ooooh [15:29:05] the rrxpdr to flightbus cb [15:29:08] at least if it is a permanent wiring [15:30:36] probably why I get weird behavior from it [15:30:56] RNDZXPNDRFLTBusCB.Init (264, 314, 29, 29, srf[SRF_CIRCUITBRAKER], srf[SRF_BORDER_29x29], Panel225CircuitBreakersRow); [15:31:16] that one [15:31:23] and according to the CSM Systems Handbook it has a 10A max [15:31:26] so change that line to [15:31:38] RNDZXPNDRFLTBusCB.Init (264, 314, 29, 29, srf[SRF_CIRCUITBRAKER], srf[SRF_BORDER_29x29], Panel225CircuitBreakersRow, &FlightBus, 10.0); [15:32:40] awesome. thanks a bunch [15:32:52] no problem [15:33:05] some things that aren't implemented yet are already wired that way [15:33:09] but not everything it seems [15:35:36] is that why the fuel cells have reduced cooling? reduced power usage? [15:39:37] not sure what you mean [15:44:32] maybe I misread something in the code. I'll have to look back at it later. [16:00:56] what's the connection of something not being wired and reduced cooling? [16:01:12] I think our fuel cells are not 100% implement according to all circuit breakers, sensors etc. [16:01:17] implemented* [16:01:33] so I think a small number of circuit breakers don't do anything [16:01:57] and maybe that leads to the fuel cells not having the right amount of heat or power or something [16:03:11] is that what you mean? [16:06:35] no connection just curious [16:09:52] in any case, when you go through the list of the Init functions for the CBs and it's missing a bus or other CB it is wired to, then you know it's not implemented yet [16:10:02] so there is a decent amount of unwired CBs still it seems [16:21:13] ahh. okay. [16:39:12] morning! [16:39:24] hey [16:40:42] what's up? [16:59:09] hey Mike [16:59:14] finally got up to undocking [17:01:14] nice :D [17:20:05] so i might be reading this wrong, but it looks like when the current function in circutbreakerswitch is called it only updates Amperes if state != 0 [17:25:25] was trying to check current draw in the heater vs power state with a debug string [17:28:18] we usually check on the voltage of a circuit breaker to see if it has power [17:28:48] CircuitBraker.Voltage() > SP_MIN_DCVOLTAGE [17:33:06] but yeah, it seems the Amperes isn't getting updated [17:33:17] hmm [17:34:19] the circuit breaker class is derived from the e_object class [17:34:31] e_object::UpdateFlow is a function that gets called every timestep [17:34:42] but even there it only updates the Amperes if Volts > 0.0 [17:39:13] I imagine to prevent division by zero somewhere? [17:40:19] I dont want to add code that creates unremovable current loads to busses [17:40:48] I don't think you really need to add that kind of code [17:40:54] I would check if the CB has voltage [17:41:00] and if yes you can use the Amperes [17:41:15] if not, well the current is definitely 0 then [17:42:03] and the things upstream of if know that, I presume [17:44:25] like if I open the cb the current through the bus drops? [17:45:02] it must, otherwise many things would be broken [17:49:33] the power_load is definitely getting updated all the time [17:49:50] might just be an oversight with Amperes because that specific variables isn't used that often [17:50:00] but power_load and Volts definitely are [17:53:07] okay. I'm happy then. [18:31:40] what's going on in the world of Apollo 9? [18:34:23] undocking now [18:36:40] I don't like that they were not running P47 for undocking [18:37:19] there is a small downrange error caused by that and that's not going away for the whole rendezvous [18:37:29] have to check all the available documents again [18:43:04] hmmm [18:43:17] apollo 9 flight journal doesn't quite go up that far [18:43:27] but I imagine they would have mentioned starting it in the transcript [18:45:13] good morning [18:45:31] hey [18:49:07] indy91: https://historycollection.jsc.nasa.gov/JSCHistoryPortal/history/mission_trans/AS09_LM.PDF [18:49:16] PDF page 133 looks like about the right area [18:52:53] hey astronauthen96__ [18:53:07] thewonderidiot, thanks. I am fairly certain they didn't use P47, I just don't like it :D [18:53:14] hehehe [18:53:15] I am checking if everything else is right [18:53:17] attitude etc. [18:56:06] I'll just wait a bit longer with undocking, then the undocking attitude is radial up from the Earth [18:56:31] and then perfectly nulling the relative velocity to the LM [21:12:49] night! [03:59:11] evening [04:07:11] hey [04:19:40] what do you know about the connector class in NASSP? [05:08:50] n7275: hey sorry for super slow reply [05:08:54] I know absolutely nothing about it :D [05:09:29] the only time I've ever really messed with NASSP code was tweaking the apollo guidance stuff to interface with my AGC monitor board [05:16:08] ahh okay [05:16:24] I'll have to bug Nik about it in the morning [05:24:02] no worries about the responce time :) its all good [16:17:31] hey [16:18:15] hi [16:19:03] I decided to run gource on NASSP development. should make for an interesting video [16:19:55] haha nice. Does it have all the commits from way back as well? [16:20:19] it starts in 2005 [16:20:43] ah great [16:22:40] NTRS has been updated [16:22:49] it's kind of... worse than before [16:23:08] and they don't seem to have readded any more of the old documents they used to have [16:23:14] was kind of hoping they would do that [16:24:48] stuff that used to be on there before the great NTRS blackout? [16:25:22] yep [16:27:14] that's unfortunate [16:28:38] oh crap, gource ran out of hard drive... [16:28:46] in 2008 [16:29:35] didn't get that far then haha [16:29:58] I'm kind of trying if the new NTRS content hosting system has some weaknesses... [16:30:30] oh? [16:32:15] they could always overlook something and the documents are actually still accessible [16:32:17] but I doubt it [16:33:54] they have a phone number +1 757-864-9658 [16:34:11] may if we all call and bother then enough... [16:34:19] probably not tho [16:34:41] oh, I have successfully gotten them to put some documents back [16:34:52] revisions of the LM Data Book [16:35:00] but it was a months long process [16:35:25] and at some point they removed the contact form for that process [16:35:35] so they kind of don't want people to try that I guess [16:35:58] oh wow [16:36:50] they actually have to ask the NASA center that was responsible for a document to do a review if it can be published [16:37:13] and they did reject a few requests we had done, so it's not a given they add it back [16:37:59] they rejected the request for the main LM Data Book document for example [16:38:10] who knows why, maybe too much engine stuff [16:38:25] but then the revision documents also had updated for engine numbers [16:38:57] I doubt they really do or can do a very knowledgable review of a document from the 60s... [16:40:49] that stuff really should be publically avaliable. [16:41:21] it used to be [16:41:28] I remember [16:41:37] bunch of shuttle stuff too [16:41:46] the worst thing, it's super inconsistent what is available now and what is not [16:41:59] best example is the Launch Vehicle Operational Trajectory [16:42:07] which contains numbers which we can directly use for our LVDC [16:42:21] the Apollo 14 one is publically available [16:42:26] and was never taken down I think [16:42:33] the Apollo 11 one is restricted now [16:42:39] but still available on archive.org [16:42:51] so we got that one through the archived NTRS [16:43:01] we requested the one for Apollo 10 and were rejected :D [16:43:20] the documents really don't differ that much [16:43:33] so they should either all be ok to be published or not [16:44:33] and I think the Apollo 10 one was never publically available [16:50:58] I wonder if someone like the AIAA could help us? [16:54:00] probably not [16:54:20] the National Archives also have copies of most old documents [16:54:32] and Ron from the Virtual AGC project has scanned a bunch of those for me [16:55:16] but in Fort Worth they only have an archive of MSC (now JSC) documents [16:55:23] the LVOT is from Marshall [16:58:33] the VAGC people probably have far better contacts than I do. [17:00:07] yeah, Ron has scanned all of the AGC schematics from MIT they also have there [17:00:30] and was in the process of scanning LM schematics from Grumman when COVID happened and they closed [17:01:40] yeah, that further complicates things [17:04:05] doubt anything's opening back up this year [17:06:11] hey, I had a couple of development questions I need a little help on [17:15:14] was trying to figure out how connectors work, and I'm not having much success [17:21:42] yeah, the connector class is a bit complicated [17:21:51] what do you want to know? [17:22:54] morning! [17:23:28] I see where they get created and initialized, but I'm not seeing where sending and receiving happens [17:23:34] hi mike [17:25:59] hey [17:26:12] each specific connector class has a ReceiverMessage function [17:26:33] ReceiveMessage* [17:26:56] and for send functions, look in iu.cpp [17:27:02] e.g. [17:27:02] IUToCSMCommandConnector::SetLVRateLight() [17:35:58] yeah new NTRS is... not that great [17:45:19] oh. I can probably figure this out. I think visual studio was just taking a break from searching properly [18:08:49] yeah, NTRS can only show the first 10 search results now :D [18:13:29] hahaha I was going to ask if you had figured out a way to see more :P [18:13:35] that is nigh unusable [18:23:35] they had to quickly get it done before the weekend :D [18:23:53] hehehe [18:38:48] hmmm, so I've started to take a look at ggalfi's agc_engine changes [18:39:04] I ported them to standalone virtualagc so I could poke at them [18:39:21] it doesn't pass all of the Borealis self-tests anymore [18:40:47] oh interesting [18:40:53] thanks for looking into that [18:41:04] the instruction tests are all fine but hardware alarms aren't quite working [18:41:11] I have only been making slow progress with Apollo 9, the heat wave is getting to me :D [18:41:20] hahaha totally fair [18:42:55] any clue what is breaking the alarms? [18:43:09] not really... there is a lot of changes here and it could be anywhere [18:44:13] hmm [18:48:05] he also made the DV instruction take 7 MCTs instead of 6 for some reason... that's not right [18:50:00] I wonder when he branched off the main NASSP development [18:50:38] well, the last Virtual AGC update in NASSP was more than 2 years ago [18:50:45] so I doubt he has an outdated version there [20:45:04] night! [01:07:19] .tell indy91 can you confirm that options 6 and 7 for V57 in Sundial both do gyrocompassing tests? [01:23:06] .tell indy91 also V57 option 14 is very strange. I disassembled it a bit and it appears to sum erasable memory in the same way that the bank summing works. you put ebank in R1, start address in R2, and end address in R3, and then it displays you the sum in address 753 [01:56:14] .tell indy91 (so to sum E5,1400 to E5,1403, you would put in 5 in R1, 1400 in R2, and 1403 in R3) [04:04:17] .tell indy91 so I'm sorry to keep bothering you with this connector stuff, but I'm pretty sure I figgured it out, and I'm just looking for confirmation [04:07:08] .tell indy91 the only place that ReceiveMessage is ever called is line 102 of connector.cpp, Connector::SendMessage() calls it [04:10:17] .tell but most (all?) connector-derived classes have their own implimentation of ReceiveMessage [04:11:24] .tell indy91 but most (all?) connector-derived classes have their own implimentation of ReceiveMessage, correct? [04:13:25] .tell indy91 might have been easier to figure out in the daylight hours, but my computer got "Gourced" pretty hard... [15:58:32] . [16:01:05] n7275, yeah for any new type of connector you need to create a new class that overloads connector functions, especially ReceiveMessage [16:44:15] morning! [16:44:20] hey Mike [16:46:14] got a restart in P52 [16:46:22] uh oh [16:46:29] but I think it's mostly my fault [16:46:39] I think I did the marks one display before I should have [16:47:06] I think I marked when I still had the flashing 01 71 up [16:48:13] was it an abort or just a restart? [16:48:59] I had a restart light [16:49:05] I can try to replicate it if you want [16:49:11] restart light but no program alarm? [16:49:20] yes [16:49:30] heh [16:51:25] does it store anything alarm data just for a restart? [16:51:28] any* [16:51:58] yeah [16:52:21] ah, should have saved a scenario or core file then [16:52:24] RSBBQ [16:53:01] E3,1432 and E3,1432 are the BB and Z registers at the time of restart [16:53:04] I'll save before I get the Insertion Maneuver PAD and then go back [16:53:21] hopefully it's as simple as doing 1 to 5 marks on the wrong display [16:53:31] *and E3,1433 [16:53:45] other than that it's been going great [16:54:22] great [16:55:07] no 06 49s at all [16:55:18] might also have to do with the higher threshold in the padload now [16:55:20] oh huh [16:55:24] yeah maybe [16:55:32] but the TPI0 time is closer to planned as well [16:55:42] so that tells me everything is very close to planned [16:55:47] including onboard state vectors [16:56:43] so I don't think it's some issue that causes 06 49s not to happen [16:56:54] it's just all more accurate than the last rendezvous [16:57:07] excellent :D [16:57:50] because of no P47s running at undocking the key is nulling the relative velocity between CSM and LM [16:58:17] for station keeping [16:59:08] and undocking attitude I guess [16:59:18] least amount of downrange velocity [17:00:10] makes sense [17:02:17] ok, first attempt of reproducing it failed :D [17:02:32] but somehow it switched to the next display [17:02:39] maybe the auto checklist did something [17:03:46] after that I'll look at Sundial [17:06:26] hmm [17:06:40] I really must have done some weird sequence of DSKY inputs and marks [17:10:05] hehehehe [17:10:26] yeah sadly I can't reproduce it [17:10:40] ah well [17:12:11] so what can I check in Sundial? [17:12:18] option 6 and 7? [17:13:35] yeah, those are the only two I'm not clear on [17:13:45] the JDCs and checkout procedures do option 6 for gyrocompassing [17:13:49] so we know what that is [17:14:05] but that code is very different, and option 7 looks like the gyrocompassing code from all of the other ropes [17:14:25] so I'm trying to figure out what or why, heh [17:20:27] ok, option 6 [17:20:33] flashing 06 61 [17:21:03] first V33 didn't really do anything [17:21:09] but the second did [17:21:24] IMU aligned to pitch 90°, others 0 [17:22:27] and it is showing +00000 +00000 02546 [17:22:40] you should be in major mode 05 [17:22:45] and at some point it will switch to 02 [17:22:56] yeah it switched to 05 [17:23:07] that's when it goes from vertical erection to gyrocompassing in option 6 [17:23:08] still doing something [17:23:28] sounds like a P11 prototype [17:26:00] I'll also try entering numbers there [17:26:09] hmm okay [17:26:12] maybe that's roll and yaw angles or so [17:26:26] still doesn't want me to do anything [17:26:34] JDC 12222 is all about option 6 [17:27:11] fast forwarded a bit [17:27:14] switched to P02 [17:27:29] https://archive.org/stream/apertureCardBox475Part1NARASW_images#page/n1279/mode/1up [17:27:37] should have been 5 minutes according to the JDC [17:27:48] sounds about right [17:28:32] guess I should do the procedure according to that document [17:29:54] ah great, they still haven't fixed that 90° rotating issue [17:33:43] ah and there I can enter the test site latitude [17:33:46] so no padload needed [17:33:53] as usual for these procedures [17:33:58] it lets you enter everything [17:34:23] I entered 45° according to the procedure and it gives me that in roll [17:34:36] well [17:34:37] kind of [17:35:12] 45° is probably the launch azimuth, 180° I also entered the launchpad azimuth [17:39:00] P02 [17:39:07] I check 06 20, gyro compassing works ok [17:41:01] V52 and it switches to P03 [17:43:53] then it's something optics test [17:43:57] some* [17:44:08] yep [17:44:19] sounds like that's working well [17:46:27] although I get large gyro errors [17:46:32] maybe I did something wrong [17:48:01] but I think the procedure is according to that document [17:48:41] do we have this for option 7? [17:48:58] no, I haven't found any documentation whatsoever describing 7 [17:49:17] but the code for 7 looks much more like the gyrocompassing tests in Aurora and Sunburst [17:49:18] well then I have to try it :D [17:49:49] I get P07 [17:50:08] but similar displays [17:50:40] hmm, then 06 66 [17:50:49] +00900 +00000 +00001 [17:50:59] not sure what to do there [17:51:25] hmm [17:51:26] what is 66? [17:52:05] "System Test Results" [17:52:07] uhh [17:53:22] I'll just do a V33 [17:53:57] drives the IMU to pitch 0 and roll 45 [17:54:57] I think it's gyrocompassing [17:56:01] cool [17:56:03] maybe N66 is different in Sundial [17:56:13] not according to these cards we have from Don [17:56:33] let me look up the Aurora procedure for gyrocompassing [17:59:37] hmm [17:59:47] these documents are using option 6 for gyrocompassing in Aurora [17:59:57] but our Aurora (and Sunburst) doesn't even have an option 6 [18:01:20] maybe they are too old... [18:02:40] oh, ND-1021042 is better about procedures than ND-1021043 [18:02:43] does that have something... [18:03:40] hmm, not really [18:04:56] I find that +00900 curious [18:04:59] in R1 of N66 [18:05:03] I didn't enter that anywhere [18:05:14] must be some value it loaded by default [18:06:29] got a program alarm [18:06:36] how do I look at that in Sundial? [18:06:53] uhh [18:07:40] ah I also got a restart now [18:07:49] and it showed up itself [18:07:51] V05 N31 [18:07:53] heh [18:07:57]