[18:45:13] NASSP Logging has been started by thewonderidiot [18:45:17] Guenter! [19:12:46] gotta wonder what prompted that lol [20:58:30] random restart. That's more of a Windows thing :D [20:59:06] some disturbance in the internet-herlands [21:54:22] night! [15:24:37] good morning [15:25:21] hey Matt [16:18:36] how's the Apollo 11 RTS going? I think I've missed all the highlights so far, unfortunately [16:19:59] LOI-2 in half an hour [16:20:04] going well [16:20:19] he set the event timer wrong for MCC-2 and got a TIG slipped alarm :D [16:20:33] but if that happens at all, on MCC-2 it matters the least [16:20:59] still no Orbiter simulation reload [16:21:04] which I find impressive :D [16:21:11] running continuously since T-4h [17:40:42] oh wow [17:41:02] maybe we finially fixed the memory leaks [17:42:21] he had performance on 9 and before without reloading [17:42:26] performance issues* [17:42:35] on 10 there already has a VC upgrade [17:42:44] and somehow that seemed to have made it better haha [18:00:56] morning! [18:02:10] hey Mike [18:04:06] what's up? [18:05:23] well at the moment, finding a birthday present for my half-brother, 10 years old in a few days :D [18:05:34] Lego is so expensive... [18:05:46] I think I found a good board game [18:11:03] oh man yeah lego is crazy expensive [18:16:25] they already have enough anyway. 2/3 of it from the 90s when I had Lego :D [18:16:58] hehehe [18:17:12] I was a K'nex kid [18:17:43] I didn't have much lego but I had a whoooooole lot of k'nex lol [18:19:58] didn't have much of that, but I remember it was around [18:23:27] I definitely created some unholy hybrids of those two at some point as a child [19:39:22] n7275, ever seen this document before? https://www.ibiblio.org/apollo/Documents/Apollo%20Command%20System%20-%20Ground%20Net%20Data%20Flow.pdf [19:42:19] thewonderidiot, my top priority from NARA is probably still IBM RTCC documents. But, I don't even know yet if they have any. Should I send some emails to figure that out before you go there? I do know exactly how the documents are called and maybe even in which part of the record group they would be, contractor technical documents. [19:44:54] they might give you these 1000 page volumes and I will have a list prepared of the (few) flowchart pages I really need :D [20:17:16] hahaha alright sounds good :D [20:17:26] yeah if you could try to determine their location before I go that would be great [20:18:09] ibibilo is giving me a 503 let me see if I can find it my archive [20:21:55] thewonderidiot, I will try [20:22:12] n7275, alternative link: https://web.archive.org/web/20100514005304/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072732_1979072732.pdf [20:27:30] oooooo [20:33:15] get ready for me to get lost in network simulation in 2024 [20:35:43] I accept and encourage it [20:36:29] if I can at some point simply access the database with telemetry data in the RTCC MFD for displays, that is all I need haha [20:36:37] this document is mostly uplink stuff though [20:36:43] even shows a MOCR display [20:36:56] I made ours with the RTACF version, not very different [20:39:45] have to go, cya! [14:13:18] good morning [14:22:53] hey Matt [15:11:24] 1 minute to PDI [14:47:16] hello [14:51:25] hello hello [14:51:37] Turry had an interesting AGS issue [14:51:42] DEDA doesn't respond anymore [14:51:50] so we wrote off the AEA [14:52:02] AEA doesn't take any readouts or enters [14:52:14] AEA doesn't seem to do any cycles [14:52:22] but if I load his scenario it works fine [14:52:29] must be a consequence from not reloading [14:52:38] but haven't found a clue what it could be yet [14:53:03] I might consult Mike and CaptainSwag, maybe they have an idea [14:53:10] could be the emulator or NASSP code [15:18:57] very weird [15:19:03] no reloads so far? [15:19:44] no reloads [15:20:42] I wonder if some counter overflowed [15:20:58] yeah, that is what I am checking for [15:21:11] there are two candidates I saw, but they are saved/loaded [15:21:23] and I had no issue after loading, so, can't be those [15:21:29] but probably something like that [15:21:31] some counter [16:11:42] morning! [16:11:45] weird [16:15:26] hey Mike [16:16:36] hi Mike [18:14:44] thinking about PCM again today [18:15:41] that document you sent me, indy91, has some frame diagrams that make me think about more efficient methods of decoding [18:23:31] oh I am sure there are some great efficient methods to handle it [18:23:38] the amount of data is not small [19:11:12] I suspect that the hardware of the MSFTP plays a role equal to or greater than the software, otherwise I don't really see how it has enough memory [19:19:15] oh yeah [19:19:32] scaling the telemetry data is done in software then, in RTCC code [19:19:42] large data tables in, large data tables out [19:19:53] but the "in" part is where the MSFTP etc. play a bit role I guess [19:23:41] I think the Univac 642Bs play a larger role in this than I originally thought [19:24:04] they can change the format in the MSFTP dynamically [19:33:46] I feel like I have often heard someone say in the background of MOCR audio "format is now X" or so [19:33:57] maybe some things had to be manually switched like that [19:34:20] a bunch of interesting related MOCR audio loops [19:34:23] network etc. [19:35:48] yeah, I should probably listen to some of those. [19:36:31] I've listened to a lot of RTCC and a bit of CCATS. I need to work my back up the chain [19:36:45] sometimes what you hear faintly in the background is the most interesting part [19:36:53] but nowhere to be found on other audio [19:37:07] like the whole EDS test conversation between the crews and LCC people... [22:09:51] night! [04:56:29] htop [15:57:56] hey [16:02:33] morning! [16:08:28] hey Mike [16:08:50] I think I have an idea what the AEA problem is [16:09:08] oh yeah? [16:09:48] when you stop the AEA, don't reload and start it again [16:10:04] the it actually does all the computer cycles to catch up the cycles it missed [16:10:13] then* [16:10:22] hahahahaha ohhh [16:10:30] which is of course a bug in itself [16:10:38] doesn't happen if you reload and usually the AGS is off for many hours [16:10:46] but the number of cycles it has to do then [16:10:56] that can overflow [16:11:08] I think [16:11:17] have to confirm it [16:11:26] then it thinks it needs to do a negative number of cycles [16:11:36] and never does any again [16:11:46] not unless you reload [16:11:56] right, that makes sense [16:12:04] so my background experiment of leaving yaAGS running for several days will very likely not reproduce anything :D [16:12:12] haha [16:12:25] it's NASSP code that is the problem [16:12:38] I took some code for the Virtual AGC there [16:12:50] but the Virtual AGC, if it is unpowered, resets the time for the cycles [16:13:04] so when it is powered up again it works properly [16:13:18] only does the cycle for the timestep [16:13:31] that reset is what the AEA seems to miss [16:14:21] gotcha [16:14:38] nice find :D [16:15:21] I was already thinking about the responsible variable [16:15:37] it just had to occur to me that it will have the time of the last AGS shutdown [16:15:57] and for some reason I thought "long" is 64 bit [16:16:09] and not 32 [16:17:27] 2097.2 seconds [16:17:39] depends on the architecture lol [16:17:52] that is when the overflow occurs [16:18:05] oh man yeah that is not long at a ll [16:18:21] kind of surprised nobody had this issue before [16:18:34] everyone following normal procedures [16:18:46] or reloading after many of sim time [16:18:59] many hours* [16:19:12] in the case of Apollo 11 you turn off the AGS at... [16:19:28] maybe 104:45h [16:19:42] turned on again, 122h [16:19:56] and maybe people have had it before and just reloading then [16:20:09] reloaded* [16:20:21] and then it was fine [16:20:53] yeah, could be [16:21:03] or if they had the AEA turned off for a short time, it just did the cycles [16:21:13] probably will cause a long timestep [16:25:59] hello [16:27:11] hey Matt [16:33:37] interesting find [16:33:59] I'm supprised Ryan has never encountered this [16:44:23] yo [16:57:09] hi Mike [17:26:10] so I had a bad idea a few days ago and proved last night that it's at least technically feasible [17:26:48] I kind of want to make my CDU simulator interactive, instead of just running in slow verilog simulator tools [17:27:39] turns out, it's possible to translate the verilog into C++ through a tool called verilator, and then translate the resulting C++ into javascript/webassembly using emscripten [17:27:54] so I have a small chunk of CDU logic running at much higher speeds in a browser :D [17:29:25] ahh cool. I ran accross that when you started on your LVDC verilog project and I googled "verilog to C" [17:29:56] is that up on your site? [17:31:42] I haven't put anything up yet, I just got the toolchain basically working last night [17:32:05] it remains to be seen how well it actually works, but it's promising so far :) [17:48:24] the LVDC would probably be annoyingly slow even with the speeds afforded by the translation/optimization :D [17:48:38] needs 168 clock cycles of a 2.048MHz clock to complete a single instruction [17:49:19] the fastest clock the CDU has is 51.2kHz from the AGC, which gives me more hope that I might be able to run it reasonably quickly [18:05:29] LVDC is probably a bit much to simulate at that level of detail [18:05:46] FPGAs are really cool. I need to get one to mess with [18:07:13] you should! they're great fun [18:07:31] indy91, I wonder if that AEA issue you fixed can occur in our telemetry code anywhere [18:07:47] do you have a particular model you'd reccomend to start with? [18:08:02] 99% sure it can't [18:08:17] there already is code resetting stuff when powered down [18:08:30] https://digilent.com/shop/cmod-a7-35t-breadboardable-artix-7-fpga-module/ is what I've been using for all of my projects recently. very small footprint, decent number of pins, beefy Xilinx FPGA [18:08:42] ahh good [18:08:55] for the AGC itself and telemetry cycles [18:09:18] you're right that the AEA needs to re-jump to its start address each time it's powered on [18:09:52] do you remember what address that is? [18:11:05] I think it's 6000 octal [18:18:49] "When the computer is switched to the OPERATE mode, power is applied in a predetermined sequence which prevents loss of data from temporary storage. When the voltages are at their proper levels, initial conditions are established such that the computer obtains its first instruction from memory location 6000. If this memory location does not contain an unconditional transfer (TRA, TSQ, or DLY), the next instruction will be taken from [18:18:57] y location 0001. The automatic initialization sequence also resets the overflow indicator and the Engine On Discrete Output." [18:19:26] that 0001 thing sounds like a hardware quick that you don't have to worry about, because 6000 is in the hardwired memory and will never not contain a DLY instruction [18:19:42] the 0001 address is in aea_engine_init code it seems [18:19:54] yeah. Ron went full accuracy there :D [18:20:08] the code does a check if it should put 6000 or 0001 [18:20:18] we do call that init code, but only on first load [18:20:27] load from scenarios is afterwards [18:20:37] I think it's actually slightly wrong as it is in aea_engine_init [18:20:50] so it overwrites everything the init code does [18:21:04] I'm pretty sure what's in 6000 gets executed first regardless -- it's just that if 6000 does not contain a branch, it will execute 0001 after the instruction in 6000, instead of proceeding like you might expect to 6001 [18:22:02] what software does and what code does is a bit confusing [18:22:12] like the engine discretes [18:22:23] engine on anyway [18:22:35] AGS operating manual has a list of things that get initialized when you go to operate [18:22:48] what software does and what hardware does* [18:22:58] lol [18:23:13] I think engine on discrete off is done in hardware here [18:23:25] and the rest is done in software [18:23:49] sounds like the safe thing to do [18:24:06] https://www.ibiblio.org/apollo/Pultorak_files/AEAProgrammingReference.pdf#page=28 [18:24:50] yeah. the "programmed initialization" section there says that the discretes in the I/O section assume random states at power on [18:25:02] that's probably okay for most things, but not so much for engine on :D [18:27:59] there are even more safeguards [18:28:14] like in the control electronics [18:28:29] there are separate engine on and engine off signals [18:28:40] if they are both on or off, the electronics assume you want the previous state of the engine [18:28:52] on or off [18:29:05] so spurious engine on signals without an engine off signals wont actually start the engine [18:29:19] uhh [18:29:36] if engine off is true the whole time [18:29:49] and engine on sometimes [18:30:04] it won't start the engine [18:30:15] that way around :D [18:30:22] hehehe [19:33:16] thewonderidiot, OutputPorts[IO_ODISCRETES] |= 02000; [19:33:36] does that set bit 11 to 1 and leaves the other bits alone? [19:34:00] yep! [19:34:15] ah good, I got it right for once :D [19:34:28] I think that is what I want when the AEA is unpowered [19:36:21] OUT 7040 # RESET ENG ON [19:36:35] case 07040: [19:36:48] NewDiscreteOutputs |= 02000; [19:37:00] break; [19:37:10] confirms it [19:39:35] wouldn't want to accidentally keep engine on set instead of reset [19:40:03] hahaha indeed [19:43:15] confirmed that after a reload of Orbiter with the AEA unpowered only the program counter is different [19:43:31] not any output [22:49:32] night! [16:19:41] morning! [16:20:44] hey [16:49:32] what's up? [16:55:36] I'd say there is a 50% chance I get that virus that looks like crown in the next 1-3 days [16:55:40] and you? :D [16:59:08] hahaha oh no [16:59:47] ....my dumb American brain was about to ask if it was because of Thanksgiving [16:59:54] but I think only we have that holiday in a couple of days haha [17:00:29] well hopefully you don't, whatever the cause :D [17:01:14] I guess I have a higher than usual chance as well because of that lol [17:01:18] is thanksgiving derived from harvest festivals? [17:01:24] yeah [17:01:25] we have those [17:01:30] in the country side [17:02:29] where people get way too drunk in a barn [17:02:34] hehehe [17:02:44] but it's not like a family gathering thing here [17:09:59] hey guys [17:10:16] sorry to hear that Nik [17:10:44] hey Matt [17:10:49] hopefully I get lucky [17:14:12] fingers crossed! [17:15:35] it turns out that verilator can handle "real" nets, as well as math -- it just turns it all into doubles. so more of my CDU model can be verilated than I thought [17:26:19] I've also gone back to my old time-filling activity of translating the Sunburst source to punch cards [17:29:29] haha [17:30:53] I like punch card formats now too :D [17:31:29] :) [17:32:04] mostly because I don't have to come up with my own format then [17:34:08] fixed-format plaintext is the ultimate database [17:40:38] if we do anything with tapes we should probably take some inspiration from this: http://simh.trailing-edge.com/docs/simh_magtape.pdf [17:41:00] https://i.imgur.com/NOQahW3.png [17:41:28] QRTP plots :D [17:41:30] with gnuplot [17:41:57] oh my [17:42:11] I like :) [17:44:48] and yeah, we have several tape formats in the QRTP [17:48:42] I still don't know how they get a state vector at TLI ignition in the QRTP [17:48:50] I am using a launch polynomial [17:49:14] coasting integration with venting to TLI [17:49:24] I think they took data from the EPO state vector [17:49:33] has state vectors for a launch azimuth at 300 second intervals [17:49:39] data from the EPO state tape* [17:49:55] in LVDC coordinates [17:50:03] which are launch time independent [17:50:18] so I guess they calculate the conversion matrix for a specific launch time [17:50:38] but then what. Coasting integration for a maximum of 300 seconds [17:50:42] ? [17:50:49] to get to actual TLI time [17:50:52] something like that [17:51:12] I don't think the TLI targeting had the ability to simulate venting [17:51:48] the whole user manual and program manual and 1/3 of the code. But I don't have the answer for this :D [17:52:12] ooooo nice plots [17:53:36] so how long until you ask for volume 2? [18:00:09] out of fear for rejection, probably not very soon... [22:10:52] night! [16:20:40] morning! [16:21:39] good morning! [16:22:40] what's up? [16:24:07] fixing some very bad python code I wrote last year [16:26:26] hehehe [16:26:40] replacing it with only slightly bad code? :D [16:27:49] something like that haha [16:39:17] hey guys [16:48:34] yo [17:03:28] well that 50% from yesterday is more like 99% now :D [17:03:36] but I feel decent [17:08:22] damn, that sucks [17:08:36] but glad you're not feeling too bad so far. hopefully it stays that way! [17:09:32] yeah, I would feel very lucky [17:10:19] at the moment my level of health is: still able to fix padloads [17:10:37] hahaha [17:11:30] well that's good. I don't even have covid and I'm not that healthy [17:12:57] I am sure your python code is all the better in comparison [17:13:10] my level of skill there is, I have changed a number in the archived NTRS download script [17:57:48] I'm making more progress on bad idea [17:58:10] always a good sign haha [17:58:25] mostly been working out the clocks and clock dividers I need, but I might be able to start plugging CDU modules in shortly [17:59:38] and even though the NOR gates have a nominal propagation delay of 20ns, I confirmed in normal verilog simulation that the design still closes with as high as 500ns delays, so I can supply a pretty slow clock to the logic section [18:08:46] is a time history of RR input data ever going to be useful? For like, Apollo 11 lunar descent? [18:10:44] hmm, what do you mean input data? [18:11:41] for the CDU [18:11:44] RR angles [18:11:56] oh yes, definitely [19:16:23] I will take it easy for the rest of the evening. Cya! [16:17:46] hey [16:43:14] morning! [16:43:50] how are you feeling? [16:45:07] pretty good [16:45:13] slept like a baby [16:45:33] if it doesn't suddenly get worse now then it's one of the tamest colds I had :D [16:45:49] haha nice! :D [16:45:54] they are usually short and intense for me. [16:46:26] maybe it's being vaccinated, felt like from start to feeling the worst was slower than usual [16:50:20] huh, weird [16:51:17] But I shouldn't get ahead of myself. I can be happy in a few days when it's actually over. [16:51:44] and I've heard of people who had it mild the first time and worse the second time. Maybe an exception to the rule, but it can happen. [17:00:46] yeah for sure [17:00:59] I hope it's not like that for me if I get it again. it got me pretty hard the first time [17:02:32] strange virus, so random how it affects people [17:17:59] don't start a new project to update the lunar descent planning processor. Don't do it, don't do it... [17:18:08] hahahaha [17:23:49] hey guys [17:26:44] hey Matt [18:39:16] yo [20:41:58] cya! [16:11:42] good morning [16:20:52] morning! [16:42:37] how's it going Mike [16:49:08] good! what about you? [17:00:25] good. trying to clean my office this morning