[15:43:11] NASSP Logging has been started by indy91 [15:43:12] hey [15:47:28] hey Niklas [15:53:05] going through the fastest cold I ever had lol [15:54:00] Sunday afternoon I had nothing, night from Monday to Tuesday was the worst [15:54:08] and now I am almost already fine??? [15:59:53] oh that's no fun, at least your recovery is quick [16:00:40] I had one back at the beginning of February what went on for a solid 2 weeks. and im usually pretty quick to recover [16:00:46] Yeah, I'd rather feel terrible for a night and it all being over quickly than it dragging on for two weeks [16:01:23] old German wisdom, a cold takes 14 days, if you go to the doctor it will only take 2 weeks [16:03:02] haha [17:41:22] morning! [17:43:46] hey Mike [18:04:15] hey Mike [18:05:30] what's up? [18:06:10] just taking it easy. How is the LVDC behaving [18:06:23] soooo close to running software [18:06:27] should happen tomorrow or so [18:06:37] but it's looking very promising [18:06:51] oh wow [18:06:56] that is good progress [18:07:10] yeah! it took a lot of fighting and not understanding serial processor design lol [18:07:27] can it divide now or is that on todays agenda :D [18:07:47] no that's on the "after it's running software and passing the first self-check tests" [18:07:53] ...agenda [18:07:59] multiply/divide is the very last thing going in lol [18:08:16] ah, so that comes even after initially running software lol [18:08:25] yep [18:08:33] kicking that can as far down the road as I possibly can lol [18:09:45] I'm almost tempted to start implementing parts of the LVDA before doing multiply/divide [18:09:50] but probably shouldn't lol [18:13:09] yeah the LVDA is certainly important [18:13:16] in NASSP it's mostly an I/O layer [18:13:32] it has the LVDC output register as its only data in our LVDA class [18:14:56] yeah I always imagined it as I/O [18:15:07] but I didn't know it had all of the timers and all of the interrupts and everything [18:16:31] "all" timers [18:16:35] isn't there two? :D [18:16:54] I have them in the LVDC class for convenience I guess... [18:17:15] our Saturn V LVDC is somewhat emulator-ish, using those timers [18:17:28] well yeah, only two, but still, the LVDC has 0 [18:17:31] because it was required for changing it to the generalized flight program [18:17:42] never made those changes to our Saturn IB software though [18:18:00] so that is basically Apollo 7 software then haha [18:18:04] instead of Skylab [18:19:57] in the GFP they used TIMER2 a loooot to schedule tasks [18:21:42] in the older astrionics handbook they still call it the switch selector interrupt, so I guess that's what they used it for mostly [18:23:01] oh okay yeah I've seen references to that [18:23:03] not any difference for the hardware I guess, the switch selector events were also at varying times [18:23:27] but it probably used that interrupt more then [18:26:29] the real I/O box in the IU is the "Control Distributor" [18:26:50] I think nearly all commands from the LVDA to other systems would go through there [18:27:44] that's probably the cutoff for an emulator. LVDA needs to be part of it, but not the control distributor functions [18:29:49] hmm [18:30:18] seems like the LVDA can directly talk to the switch selector(s) [18:30:41] yeah it does [18:30:46] why did I make it go through the control distributor then... [18:31:00] does it have separate lines to all 4 of the switch selectors... [18:32:34] astrionics handbook figure 4.2-1 [18:33:57] I guess it does go through the control distributor, even if it is just for the stage selection lines wiring [18:34:31] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_saturn/IUControlDistributor.cpp#L136 [18:34:36] this code makes sense then [18:35:14] ahh gotcha [18:38:21] the switch selector in the IU is the same as the ones in the stages, so, there has to be a switch selector "selector", which is just the control distributor then [18:56:58] so the other thing I need to do is figure out how to interact with this thing when I get it into an FPGA [18:57:15] having something like the AGC monitor would be sweet, but the serial nature of the LVDC is going to make that a massive pain haha [19:05:32] yeah, just something to monitor the I/O at first [19:05:57] and lacking a DSKY, with real software all you can watch is the telemetry [19:20:54] well [19:21:12] the first problem that I'm immediately going to face is that I have to write my own software for this thing to run at first [19:21:27] we only have the AS-206RAM listing and the PTC self-test code [19:21:56] PTC boots up differently and AS-206RAM does not include the startup code (it just leaves the address the LVDC restarts to completely empty) [19:24:45] but once I have it running I think I should be able to copy over most of the PTC self-tests [19:25:13] yeah the PTC is certainly the best start [19:25:16] of course the PTC doesn't have multiply or divide instructions, and I don't think we have any examples of what a correct multiply or divide should look like [19:25:24] so those are going to be doubly annoying to ensure they're working [20:11:03] are multiply/divide like a microcode sort of thing? [20:11:18] hahaha no nothing in this computer is microcode-like [20:11:34] special cases with giant and gates on flip-flops everywhere [20:12:31] like addition and subtraction, multiplication and division can only be done one (or a couple?) of bits at a time because everything is stored in the delay lines [20:13:31] oooooh [20:16:51] uhm, looking at the example code from the AS-206RAM listing [20:17:00] FIXED POINT DIVIDE ROUTINE [20:17:05] is that doing what I think it is doing [20:17:24] BY TRANSFERRING TO PARTIAL SQUARE ROOT ROUTINE A 7 INSTRUCTION DELAY IS PRODUCED. [20:18:57] is that just wasting time until divide is done??? [20:20:21] must be [20:21:14] the part of the square root routine it is transferring to is delaying by 5 cycle [20:21:29] yeah, multiply and divide happen all on their own, and unless you use MPH (multiply and halt), other instructions keep running and you just have to wait long enough for the results to be available [20:22:07] yeah, that's what it does haha [20:22:10] oh man [20:22:34] what a waste of software [20:23:13] but I guess that's why they probably put all divide calls into this utility routine [20:23:24] so that you only have to do this once in code [20:24:02] and even re-use a part of the square root routine for that [20:28:54] hehehe yeah [20:29:27] having now worked with the LVDC [20:29:45] I fully understand why MIT was offended that IBM was trying to get NASA to replace the AGC with it [21:13:22] I feel like the more I learn about stuff like this, the more I can enjoy MITs report on the LVDC [23:03:50] night! [16:27:35] hey [17:12:28] I want to finally finish a project, so I am focusing on the AGC padload generator [17:13:05] I have the same problem I had with the telemetry client. If I run the standalone exe, which is in a different folder than some files the generator depends on, then it doesn't work [17:16:07] I guess I can just have VS put the exe in that folder, release and debug mode [17:48:02] I had similar problems when I was working on my offline, console version of the harmonic gravity model [17:48:03] VS has some odd ideas about paths [17:48:58] yeah, when I run the debugger it all worked fine [17:49:10] which is what one normally does at first I would assume [17:49:26] but then when running the "production" release mode exe you suddenly get this new challenge [17:53:43] well, I put it up: https://github.com/indy91/AGCPadloadGenerator [17:54:04] definitely not great yet, but I didn't want to have it just sit on my PC in this state forever [17:54:26] morning! [17:54:28] nice :D [17:55:11] hey Mike [17:55:45] I bet I forgot some files as usual [17:55:59] it's tradition! [18:00:32] it's going to be a couple more days until I get software running on the LVDC [18:00:52] I went down a rabbit hole last night of "how do you appease the memory error detect circuits" [18:01:07] and along the way I fell down an even bigger rabbit hole of "how do you boot an LVDC in the first place" [18:01:37] I think I get it all now but I didn't get much new logic implemented last night as a result [18:02:07] ask Guenter Wendt for his giant winding key? [18:02:50] is that not how you boot it? [18:03:37] lol yeah it's something like that :D [18:16:11] well I am safe against this particular hard drive failing now lol [18:16:24] \o/ [18:16:58] speaking of, n7275 did you ever end up getting some new hard drives? [19:23:56] oh shit [19:23:57] no [19:23:58] not yet [19:42:43] I should do that soon [19:43:04] including the ones in my NAS, and webserver [22:04:20] night! [14:59:28] hello [15:02:18] hey Matt [15:03:48] nice padload generator [15:03:52] I like it [15:06:13] slightly barebones :D [15:06:32] and more options to add. And a whole bunch more ropes to support [17:47:09] morning! [18:54:01] hi Mike [18:54:14] how's the LVDC? [18:57:04] soooooo close [18:57:36] it's very mad right now because all of these memory check circuits I've been adding have it outright failing and halting instead of kind of running garbage like it was before [18:58:12] but I have two more pages of logic to implement tonight (which contain the memory buffer B parity pyramid) and I'll have everything I need to do everything except multiply/divide [18:58:38] so after those two go in, it's time to make models of the memory modules and load some real software in [18:58:46] probably about a 50% chance I'll run my first code tonight :) [19:34:42] that's awesome [19:35:06] so, how are you doing stuff like the delay lines in verilog? [19:35:40] it's actually surprisingly easy, in simulation [19:35:44] https://github.com/thewonderidiot/lvdc_simulation/blob/main/components/dl.v [19:36:02] https://github.com/thewonderidiot/lvdc_simulation/blob/main/modules/delay_line.v#L125 [19:36:30] that construct implements a straight delay on the signal [19:36:48] when I make this synthesizable I'm going to have to reimplement them as a big shift register [21:48:32] are you aiming to make a FPGA version? [21:50:10] yep! [21:58:48] awesome [18:19:20] good evening [16:26:09] hey [16:48:32] hey Nik [16:49:20] I had grand plans of working on stuff this weekend and ran right out of motivation. [16:56:00] oh no [16:56:39] I can feel it. The topics you have chosen to work on require an extraordinary amount of motivation to get something meaningful done [16:58:21] morning! [16:58:28] I mostly ran out of time this weekend. I am working a little bit on the Moon-centered RTE logic. Also fun to look at and not that frustrating [16:58:32] Always fun* [16:58:50] but then I haven't really managed to do anything meaningful with it except some cleanup :P [16:58:53] hey Mike [17:04:17] hey Mike [17:12:09] good news that I overlooked 2 weeks ago [17:12:20] they also made transcripts out of the Apollo 11 MOCR audio [17:12:26] they had already done that for 13 [17:13:00] it's a poor replacement for my notes from listening to the FIDO loop [17:13:05] oh nice [17:13:09] but it's good enough to find things [17:13:17] and of course it's complete [17:13:27] "pair of Cynthia" [17:13:29] and doesn't require me to listen to everything [17:13:31] yeah [17:13:47] finally found a full TEI calculation on the RETRO loop lol [17:14:02] I had found many instances of "use same inputs as before" [17:28:07] ahh [17:39:04] what I am making progress on is logic for the tradeoff display [17:39:20] right now that only works in Earth SOI [17:41:31] https://i.imgur.com/8FaJzLp.png [17:41:54] gives fancy graphs like these [18:04:37] ooo, that is fancy [18:05:23] I love graphs! those are very nice. [19:31:52] yeah the display is pretty great, with dynamic labels and everything [19:31:58] it just doesn't get much use haha [19:32:08] didn't get much use from the actual RETROs either [19:32:16] they generated some hardcopies for RECOVERY [19:32:21] not long after TLI [19:32:31] with the same inputs as in my picture there [19:32:55] probably useful for the recovery forces to know that if you abort at X hours you will land at what latitude and time [19:33:02] other than that... [19:33:31] not sure it was used much. If a RETRO really needed the tradeoff display then they haven't done their pre-mission prep right [19:33:47] I'm not sure the Apollo 13 RETRO generated any tradeoff display after the accident [19:49:50] cya! [15:45:33] hey [15:56:50] hey [16:01:14] I'll take a look at your PR when I have figured out this TLI PAD issue [16:13:53] no rush [16:14:00] it's pretty simple [16:15:46] found the issue [16:15:52] pretty funny [16:15:55] RTCC TLI simulation [16:16:00] pitch angle is at 175° [16:16:07] new commanded pitch angle is -175° [16:16:17] it does rate limiting [16:16:43] and then instead of going the short way around, 10° maneuver at TLI ignition [16:16:47] it tries to go the long way... [16:17:21] and that makes it run out of propellant before achieving TLI [16:17:27] and that's why the TLI PAD calculation fails [16:17:35] must be a rare case, never had this issue before [16:18:01] maybe because this is the latest TLI you would get, 3:21h ignition [16:18:23] in an older Apollo 17 scenario, with the launch delay, TLI is 10 minutes earlier and TLI PAD calculates fine [16:19:55] the LVDC itself has code to prevent this [16:20:39] but not this RTCC code based on IBM equations. Actually, the rate limiting wasn't given as equations but just a paragraph "do rate limiting here" [16:20:51] so I just have to blame my own code haha [16:21:12] oh that is interesting [16:22:30] Yeah when I fly the TLI the S-IVB does a pretty large pitchdown maneuver at ignition [16:22:46] this is the maneuver that the RTCC equivalent had trouble with [16:23:07] I guess it wanted to do a 350° pitch up maneuver instead of 10° down, that's roughly what I am seeing [16:23:30] that's a rather inefficient way to do that haha [16:26:40] yeah, the first thing I saw was that the TLI sim was outputting the error of exceeding the minimum weight limit [16:26:54] I guess you don't quite have enough fuel for a flip [16:27:04] a very slow one [16:27:29] limited to 1°/s like the LVDC [16:36:45] I bet that does wonders for the trajectory [16:41:17] haha, I should make it plot the altitude [16:56:44] tested and merged [16:57:42] morning! [16:58:34] hey Mike [16:58:47] sorry, I called you "not a DAP expert", I hope you can forgive [17:01:39] how dare you [17:01:51] but also you are 100% correct so I'll let it slide :D [17:11:32] I am only very surface level familiar with the DAP, especially the LM. [17:11:43] Your knowledge might be rather far away from the surface haha [17:13:18] I desperately studied DAP code before I even knew you, but only the TVC DAP in the CMC, Colossus 249 [17:13:28] annoying padloads... [20:03:25] yeah my knowledge of DAP is split between deep subterranean and birds-eye [20:03:47] I have a rough understanding of how the data moves around from all of the transcriptions and reconstructions, especially Sundance [20:03:55] and a rough understanding of what it does [20:04:00] but there is no understanding in between :D [20:15:10] something in the DAP seems to be confused sometimes after landing as Ryan has seen [20:15:24] but it could still be realistic behavior [20:15:56] just strange that even if you do the PRO and make desired attitude equal to current attitude then it still sometimes outputs RCS command on channels 5 and 6 [20:16:42] not sure how much digging that is worth doing, I don't really want to spend too much time on it [20:18:00] yeah it's weird [20:18:06] a lot of DAP stuff also gets zeroed on PRO [20:19:05] it almost seems more like something is stuck than the DAP really actively deciding that more RCS needs to fire [20:19:20] right [20:22:45] thewonderidiot, I have your LVDC running on my Pi [20:25:07] hahaha oh boy [20:25:45] oh I have probably been doing a bad job keeping my gtkwave save portable [20:26:21] https://github.com/thewonderidiot/lvdc_simulation/blob/main/lvdc.gtkw#L22 [20:26:41] these can be manually edited to relative paths (or absolute paths for your machine) if you want a better waveform viewing experience [20:34:14] the self-tests have been going very smoothly after the insane struggle it was to make it past the first four instructions [20:34:56] I might pivot back to the hardware side and put in the three multiply/divide modules soon, before finishing off the rest of self-test [20:37:09] oh that would be handy [20:38:40] I had to build iverilog 11, because the package for PiOS3 is still 10. [20:43:53] oh do I use features not supported in 10? [20:44:06] I've never really thought about iverilog versions [21:48:36] night! [03:41:51] thewonderidiot, yeah it gets mad about this line https://github.com/thewonderidiot/lvdc_simulation/blob/bb309b72564de906e9834657a97fe622fd2edc7c/modules/memory.v#L186 [03:42:22] ohhh yeah I could see that [03:42:28] that line took a lot of experimentation to get working haha [03:43:40] it's also possible that it's a problem with the particular build of 10.0 that was packaged for PiOS [17:42:39] morning! [17:48:35] hey Nik [17:50:57] good evening [17:51:41] got a fun saving/loading issue? [17:55:30] it would appear so [17:58:10] although I have no idea how that's possible [18:02:05] TransmittingGroundstation has to be non zero, for there to even be a check for signal strength, that's the same check required for saving too. [18:42:55] n7275, I'll take a look at the issue for a bit [18:43:01] I'm the master of saving/loading bugs [18:43:06] as in, causing them [18:51:56] hmm [18:52:26] could it be that our MCC logic only does Moon occultation logic for the CSM [18:52:35] so if CSM is in LOS then LM also is... [18:57:50] oh wait.... [18:58:58] what happens if the LM is on the surface, and the CSM is behind the moon [19:01:00] I'm thinking we need that calculation for both vessels [19:02:45] yeah, I think that's the issue [19:02:51] I get LOS in the LM when the CSM has LOS [19:03:00] oops [19:03:09] probably how I should've done it from the beginning [19:03:26] we didn't consider this when we made the switch to using the MCC AOS/LOS calculations [19:04:27] it works for Apollos 7 through 10, at least to the degree that it would be noticable [19:04:57] yeah, AOS/LOS times only differ by a few seconds if CSM and LM undocked [19:05:12] maybe a bit more on 10 with the LM in the descent orbit [19:07:22] quite the oversight dammit [19:11:28] I'm surprised this situation didn't even occur to me [19:11:45] same [19:16:31] I'll work on fixing it [19:16:42] not going to be easy [19:18:59] the question is also, should there just be two calculations where there is only one right now [19:19:13] or some more elegant way with it being dynamic [19:23:22] maybe we should look it at from a real world perspective [19:23:57] how did talking to and tracking two separate spacecraft close to each other actually work [19:24:18] good point [19:24:37] I know they're separate frequencies [19:27:49] I don't know if you can just send 20kW signals into a giant mixer and blast it out through a single antenna [20:01:59] I need to do some reading [21:38:50] night! [16:18:48] morning! [16:20:36] hey Mike [16:21:01] what's up? [16:30:29] not much, reading up on "Station Configuration Messages" for ground tracking again [16:34:31] sounds pretty dry :D [16:35:37] I won't disagree with that haha [16:41:17] my eyes have been glazing over reading through the description of LVDC multiplication [16:41:41] holy cow did they complicate that lol [16:49:09] sounds like IBM to me :) [16:51:43] I'd be curious to know if you can see any of the design decisions that lead to oddities in the LVDC in their more "terrestrial" computers [17:02:57] yeah me too [17:03:12] I've never looked at any of the old IBM computers [17:22:14] if you need any distractions http://mwhume.space/Files/I7000/I709/ [17:25:30] nope no thank you lol [17:26:12] between today's shipment that should be here in a couple of days, and this: https://twitter.com/RocketLab/status/1636406578713862144 [17:26:17] ...I'm going to have my hands quite full :D [18:13:09] hey Nik [18:16:27] hey Matt [18:17:10] I think I am in favour of just doing the AOS/LOS calculations twice [18:17:17] once for the cm and once for the lm vessel [18:17:34] and put them in two different calls in clbkGeneric, which stand for two different frequencies [18:17:56] two different cases* [18:18:24] yeah I think that's the simplest method [18:18:28] and with the MCC AOS/LOS calculations, just put that in a function to prevent code duplication [18:18:43] it's mostly realistic because MSFN can't track an infinite number of vessels [18:19:59] there is a note on the HSK website (for which I'm trying to track down a source), that says the transmitter bandwidth was wide enough to cover both vessels [18:46:58] I can probably tidy up some of that code a bit better this time around too [18:51:13] sure if you want to tackle this, go ahead [18:51:28] it could definitely use some tidying up, especially the oldest MCC code for AOS/LOS [21:57:20] night! [13:59:46] hey [14:02:02] hey [14:11:38] got a plan yet for the AOS/LOS stuff? [14:13:10] I have a plan [14:13:49] great :D [14:14:19] I'm going to add a second "AOS" variable to the groundstation [14:14:41] AOS_CM, AOS_LM [14:15:30] and that while loop will become a function that gets called with a vessel pointer as an argument [14:16:29] yeah that makes a lot of sense [14:16:40] what about the MCC internal stuff, like showing the AOS/LOS messages? [14:17:05] it would kind of make sense to show that separately for CSM and LM, but only in some cases... maybe only do it for the CSM, but I am not sure [14:18:17] showing messages for both could be kind of messy [14:18:44] yeah [14:19:28] so you will either have to separate that display code from the AOS/LOS calculations or leave it in there, but have another function argument so that it only shows up with the CSM [14:19:29] especially for Apollo 9 [14:20:04] yeah: bool displayMessage [14:20:05] or something [14:20:19] or if you want to get really fancy you check the distance between CSM and LM and show separate message above X km :D [14:21:12] but that could be added later [14:21:36] yeah [14:23:04] we could hypothetically use this for SIVb tracking as well at some point [14:27:22] riiiight but then you get into the Apollo 13 style issue where they couldn't track LM and S-IVB simultaneously [14:27:36] or only with great difficulty [14:43:04] I presumed we'd do something like, use the LM AOS slot to track the SIVb [14:45:09] ah yeah, we could do that [14:50:33] I'm still tinkering around with the moon-centered RTE logic. Can't say I have made any big steps forward, but it's kind of fun to work on it, understanding a bit more and doing small improvements [14:50:50] understanding Fortran more is definitely helping a lot compared to last time I was looking at this [14:51:16] two variables that seem to be the same but have different names? Doesn't have to be an error, just some EQUIVALENCE [14:51:43] I/O of a function is a bit unclear? Might be because numbers are input or output via a COMMON [14:52:45] the MSC memos with RTCC Requirements are the main source. I do have a handful of these RTE functions in the IBM documents, there they seem to use normal calling arguments for input, but output is via a common [14:56:01] would get a bit out of hand otherwise, one of these functions has 15 inputs and 7 outputs :D [15:42:43] I/O can vary quite a bit depending on the computer/OS [15:49:26] morning! [15:56:02] hey Mike [15:56:42] got a certain delivery yet? [16:00:04] no, I don't have the tracking number yet [16:02:21] the LM-2 AOH vol2, which got lost in shipping, was just found this morning though [16:02:26] so that's another delivery that should happen soon haha [16:03:29] oooh, that's great! [16:17:31] ohhhhhhhh man now I have the tracking number for the certain other thing [16:17:39] the package is 40 pounds :D [16:17:54] / 18.14kg [16:18:01] I just had to ask and now things are happening [16:18:11] I wished this actually worked... [16:18:22] lol [16:22:24] now would also be a good time for a lawyer update :D [16:59:47] the lawyers told us not to bother them about this new software until we actually had it [16:59:51] (but in a nice way) [17:00:41] that's the difference? [17:00:45] what* [17:01:31] essentially they just didn't want to worry about it until we actually had it, instead of just saying that we might get it [17:01:44] why would the newer software be treated any different than the older one? [17:01:46] no use spending cycles on something that may or may not happen [17:02:33] everything that is potentially problematic applies exactly the same to both [17:03:01] so why do they even need to care that there is anything new [17:04:47] I don't know [17:04:50] lawyers lol [17:05:02] haha [17:05:05] I think they're filing some paperwork about the specific thing [17:05:41] I'm smelling some positive news, just for the newer software to take 5 more years to be freely available... [17:07:37] which would make no sense at all of course [17:07:45] lol [17:07:48] of course [17:15:46] on the other end of the spectrum my next delivery is 24 grams [17:16:06] hahahaha that is quite tiny [17:16:36]