[19:49:59] NASSP Logging has been started by thymo [19:50:03] a [19:50:10] Right :P [19:50:49] and .endlogging just to restart now [19:53:39] sounds good [20:03:54] endlogging was only used a few times when the file size of the log got too big, I guess [20:07:40] yeah [20:12:42] lol this last bank of sundial is going to be a real problem though [20:15:31] why that? [20:16:37] it's a bunch of gyrocompassing/prelaunch alignment code (I think) that has nothing at all whatsoever in common with any other program we have [20:16:57] so it's going to be difficult figuring out what it's doing [20:17:47] if it has interpreter code I can help :D [20:17:56] yeah it's almost entirely interpreter [20:18:12] do we know what it is used by? [20:18:29] and there's some hardcoded matrices in it that aren't in any other program that might help if we can identify them [20:18:32] any of the tests we tried? [20:18:33] yeah [20:18:45] did you compare with Colossus? [20:18:49] yup [20:18:58] there's some similar constants but the code is totally different [20:19:24] I think we tried this one? at the very least I think we do have procedures to run it [20:22:36] I'm gonna just finish the skeleton disassembly and then we can dig into it a bit more [20:23:45] sure [20:57:07] night! [15:34:16] good morning [15:36:54] @indy91 i think there might be a problem with lem ejection [15:37:28] in the before docking scenario for apollo 11 the lem and csm won't seperate from the sivb [15:40:52] hey [15:41:03] which scenario? [15:41:16] before S-IVB separation? [15:41:35] yes [15:41:59] even thrusting back it doesn't work [15:44:56] hey [15:46:43] hey Alex [15:47:15] astronauthen96__, well great, I tried loading the Apollo 9 pre LM ejection scenario because that seemed like the same situation and I get a CTD [15:47:17] bugs, bugs, bugs [15:51:26] started a brand new mission and im about to tli so i'll let you know if the LM ejection works [15:54:42] AlexB_88, can you try if the Apollo 9 pre LM ejection scenario is working? [15:54:51] the CTD I am getting doesn't make any sense [15:55:18] have to check in debug mode if it's misleading where the issue is [15:59:39] it is creating the docking port for S-IVB/LM, then it is accessing the docking port and that's where it crashes [15:59:42] makes no sense [16:00:54] sure [16:06:34] oh it was misleading [16:06:39] it tries to create another LM :D [16:06:42] why is that... [16:07:35] I get a CTD [16:14:20] for some reason it thinks the LM hasn't been created yet [16:19:06] hmm [16:19:22] oh I didn't create that scenario from scratc [16:20:41] yeah I think those ones are very old [16:20:50] I just changed the padload [16:21:01] so it tries to create the LM, which is actually correct [16:21:14] but something with that doesn't work [16:21:34] worst case is I have to use one scenario older and make a new pre LM ejection one [16:21:40] but I wonder where this faisl [16:21:42] fails [16:23:36] GetStatusEx fails, weird [16:24:20] maybe that doesn't work on scenario loading [16:26:56] well in any case, I think I'll just make a new scenario there [16:35:19] but first I'll try if LEM ejection is broken in general [16:51:42] astronauthen96__, I do have the same issue, although I can't rule out yet that's it just a wrong switch setting [16:52:17] I hope it's not the transponder code messing up stuff, that also uses the connector class for communication between vessels [16:57:56] hmm [16:57:58] now it worked [17:28:55] hey i tried the the lm ejection in my new scenario and it still doesn't work [17:30:14] @indy91 can i give you a scenario? [17:42:55] morning! [18:51:08] @indy91 here is the scenario if you can check it https://drive.google.com/file/d/1VX0KvauQHE24_na7wVtbG-FtvQ7ORfHE/view?usp=sharing [18:56:40] astronauthen96__: that message from guenter means you need to turn on sharing for that link -- it's still private [18:58:47] https://drive.google.com/file/d/1VX0KvauQHE24_na7wVtbG-FtvQ7ORfHE/view?usp=sharing [19:01:47] @thewonderidiot does it work now? [19:01:59] yep! [19:02:02] thanks [20:49:13] astronauthen96__, when I try your scenario it does undock LM and S-IVB [20:49:25] but it doesn't impart any DV on either vessel [20:49:36] so you will only notice when you thrust aft [20:50:11] I wonder if that is realitic. Normally when you undock two vessels you get 0.2 m/s DV between them [20:50:26] but in this case we are actually deleting the docking port between the two, so there is no DV [20:50:59] lol, and my debug strings I just put in to find where the problem is was totally misleading me [20:51:31] as long as I kept the LM ejection switch pressed it was trying to send the signal, but after undocking it only got to the LM, not to the S-IVB anymore [20:51:47] which is of course correct, but I thought it only got up to the LM even in the docked state... [20:52:30] but, I thought LM ejection did have a problem when I started a scenario before CSM sep [20:52:35] so maybe there is a bug there [20:52:49] but not when you load a scenario just before LM ejection, will have to test that tomorrow [21:03:49] thewonderidiot, any progress with the Sundial disassembly? [21:04:23] yeah I think the initial skeleton is done [21:04:42] ah nice [21:05:41] so lots of unnamed constants and labels [21:05:46] lots and lots [21:06:10] I'm going to start setting up initial source files for it tonight [21:09:11] if we know how to run that part of the code and if we even have procedures for it then it shouldn't be too difficult to figure it all out [21:13:53] great :D [21:29:06] night! [07:39:22] morning [13:04:35] astronauthen96__, I fixed the bug! [13:05:35] it only happened if you didn't save/reload after CSM separation [13:06:14] so when I tried it in your scenario it worked fine, but if I used a scenario from before CSM separation it didn't [13:06:18] but it should be fixed now [13:37:35] hey [13:38:03] did I break the LM ejection with my transponder connector? [13:40:27] nope [13:40:42] okay good [13:41:11] I think this bug was there since I implemented Apollo 5 as separate stages [13:41:51] just had to switch two lines of code haha [13:43:14] ahh. okay. that's good. [13:45:48] it was a problem with the connectors, like your transponder code, but it was just an issue with the order of things when the LM gets first created [13:51:24] good to be finally doing some NASSP coding myself, was a bit burned out after working on Sundance so long [14:04:18] yeah, I'm slowly getting back into it myself. what are you working on? [14:11:19] LVDC [14:15:44] for the Saturn V, same update I gave to the Saturn IB [14:20:10] oh cool. [14:23:22] it's just more difficult than I thought, even though it's the same kind of update [14:31:10] is that because of the saturn class, or something specific to the LVDC itself? [14:33:45] it requires a bit of restructuring the LVDC code, and there are a bunch of additional parts for the Saturn V [14:34:08] more timebases, calculations for the TLI ignition time, for TLI itself etc. [14:36:27] so it's a bit more complex than the Saturn IB LVDC code [16:57:08] @indy91 hi [16:57:15] hey [16:57:18] I fixed the bug! [16:57:39] it was a bug, and only happened if you went from CSM separation to LM ejection without reloading [16:57:53] i was just about to say that [16:57:55] that's why LM ejection worked fine in the scenario you gave me [16:58:14] but yeah, I just had to switch around two lines of code, that should fix it [17:00:42] i made a save before lm injection and it worked then [17:00:48] but not when i kept going [17:01:39] yeah, something was not set up correctly when the LM got created upon CSM separation [17:01:51] but it got set up correctly when the LM is loaded from scenario [17:02:05] glad you found it [17:02:26] yeah, was a bit tricky, but minimal code changes required [17:03:06] https://github.com/orbiternassp/NASSP/commit/bbe3abf2fe666d5ffa7ce450c193b88d5cf879f7 [17:03:11] very minimal :D [17:17:02] morning! [17:17:28] nice :D [17:17:52] hey [17:19:56] if I ask you a specific question about the LVDC listing, about a part that is not related to rocket guidance, will you answer me? :D [17:20:26] haha probably [17:20:32] what's the question? [17:20:38] what does the first line of Section 17: Minor loop do [17:20:50] first line of code [17:21:05] or alternatively, do you see anything about liftoff at the beginning there [17:22:14] hmm, well, if it's the same as the generalized flight plan then it might start with a flight sim entry to the minor loop [17:22:21] generalized flight program* [17:23:02] basically, I have good information how things are structured in the generalized flight program, Apollo 12 and later [17:23:40] thanks to your astrionics handbook for Apollo 12, and that document with document we found on NTRS with some LVDC code in other languages [17:23:49] that document we found* [17:24:10] our LVDC++ is still based on the older structure of the LVDC code [17:24:32] so I am not sure where some parts of the code should be placed correctly [17:24:56] the generalized flight program has a task called Liftoff Search [17:25:06] that is run before and after each minor loop [17:25:13] so separate from the minor loo [17:25:15] loop [17:25:42] start of timebase 1 (liftoff) has very strict timing requirements [17:26:12] so in the old version, it has be run either in the minor loop code or in interrupt processing [17:26:15] can't imagine where else [17:27:01] hmm [17:27:38] I don't see anything about that at the start of section 17 [17:27:41] I'd really like to see an example of a time base being started in code, but that might be a whole page, a bit much to ask maybe [17:27:59] so what's the first thing it does [17:28:05] something like DVCC = DVCC + DVDC? [17:28:35] comments at the beginning are "READ REAL TIME CLOCK UPON ENTRY", "40 MS IN BOOST, 100 MS IN ORBIT", "LOAD MINOR LOOP COUNTER", "EULER ANGLE TRANSFORMATION COEFFICIENT", "Y COMPONENT OF ATTITUDE ERROR", "FIRST TIMER OF YAW COMMAND" [17:28:54] so looks like it begins with calculating commands [17:29:24] after that it calculates CHIZ, CHIX, and CHIY [17:29:28] ah yes [17:29:54] DVCC is commanded Chi [17:30:07] in three axes [17:30:19] "LIFTOFF SEARCH ROUTINE ENTER VIA SS INT." [17:30:21] ok, so I guess the liftoff search is not in minor loop [17:30:22] ah [17:30:23] oh [17:30:33] that helps [17:30:39] SS is switch selector [17:31:09] which is the other regularly scheduled interrupt [17:32:24] there are no normal switch selector commands in Timebase 0 [17:32:34] so liftoff search is probably in there [17:32:41] Timebase 0 specific code [17:32:46] I guess that makes sense [17:32:52] thanks, that was helpful! [17:33:16] that interrupt should happen every 100ms [17:33:27] the basic structure appears to be that there's a chunk of switch selector interrupt that always runs, but based on what's happening a single additional handler can be registered with it, and the liftoff search is one of those things [17:34:21] handler? registered? Didn't know the earlier program was that advanced [17:34:28] any idea how often it is scheduled to run? [17:34:41] not sure if that interrupt was already programmable [17:35:03] I only know that switch selector commands are sent out at a minimum of 100ms apart [17:35:18] not sure [17:35:31] well maybe it's just that 100ms interval [17:35:47] so they would have made the liftoff detection more precise [17:36:06] with liftoff search being called twice in 40ms interval in the later programs [17:36:36] in liftoff search it will look for the discrete input [17:36:49] there was no interrupt specific for liftoff [17:37:01] so they needed a bit of special code there to get precise timing [17:41:42] in the generalized flight program both minor loop and switch selector processor runs on one interrupt, with some smart scheduling [17:45:11] so there is a routine called liftoff search even in this listing? [17:45:21] that's how I found it, haha [17:45:23] or did you just use the terminology I used [17:45:24] ah, nce [17:45:25] nice [17:45:49] does that routine itself start a new timebase? [17:46:52] yeah it jumps to the "time base change routine" [17:47:14] ah interesting, so there is a general routine for that [18:54:28] so I didn't start the Sundial source reconstruction last night but probably will tonight [18:54:50] I was feeling pretty tired so I just did some punch-cardification of Aurora instead -- want to get back into that as well [18:55:38] I'm starting to get a little bit close to the first bit of BLK2 interpreter code which I haven't implemented in pyul at all [19:01:32] how will YUL react to instructions it doesn't know? Lots of cussing? [19:02:22] well [19:02:24] I'm not sure [19:02:36] I think it probably does know the instructions to some extent [19:03:47] yeah pass 1 already has them all defined [19:04:01] but I know for sure I didn't implement anything in pass 2 [19:04:57] so probably not good things [19:05:34] haha yeah [19:07:07] actually let's see what happens just for fun :D [19:08:21] okay I had a syntax error [19:08:28] but after that it actually assembled without crashing [19:09:13] 0326 12,2451 0 RRDESSM STQ CLEAR [19:09:14] 0327 12,2452 DESRET [19:09:14] C0327 REF 2 LAST 16 ■■■■ ■■■■■■■■■■■■■■■■ [19:09:15] 0328 12,2453 RRNBSW [19:09:16] C0328 REF 1 ■■■■ ■■■■■■■■■■■■■■■■ [19:09:16] 0329 12,2454 RTB SSP READ CDUS FOR SMNB. [19:09:17] 0330 12,2455 1 ■■■■ READCDUS [19:09:17] C0330 REF 1 ■■■■ ■■■■■■■■■■■■■■■■ [19:09:19] E■■■■■■ # 48 "READCDUS" IS UNDEFINED ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■PRECEDING CUSSED LINE IS ON PAGE 159 ■■■ [19:09:20] yeah it's quite angry [19:09:29] lots of black boxes and it's not even cussing all of them [19:10:18] well impressive that it gets that far [19:11:27] there's a big table in pass 2 that I'm going to have to untangle that I'm a bit scared of [19:12:00] https://github.com/virtualagc/virtualagc/blob/master/YUL/YUL_SYSTEM_ASSEMBLER_BLK2_PASS_2.argus#L1365 [19:12:32] encoded in that sea of numbers, as I understand it, is all of the information about how each opcode behaves [19:12:56] its input mode (double precision, vector, etc.), output mode, things like that [19:13:23] but it's not entirely clear from the table itself how it is encoded lol [19:13:37] haha [19:14:16] oh actually there's a big comment a bit lower down that explains it [19:14:19] at card R2590 [19:15:09] there's a lot of restrictions coded in there [19:15:31] I'm excited to have an assembler that checks for all of this stuff, instead of yaYUL which will happily assemble pretty much anything [19:19:54] already thought we would have to decode the table haha [19:20:48] one can encode lots and lots of information in such a table [19:40:20] well, even with that description I'm still afraid of it [19:41:05] the code to access such doubled up information is practically guaranteed to be "clever" [19:41:25] i.e. Hugh abusing the honeywell 1800 instruction set :D [19:41:30] the kind of code where I always ask you "how do I do this bit shift???" [19:42:15] yup [19:54:03] man I think I may have taken too long of a break from this, looking through the interpreter handling code [19:54:16] H-1800 assembly is just about as weird as it gets and I'm not remembering a lot of this lol [19:56:59] yeah, breaks that are too long never help with complicated projects [19:57:11] for me that often leads to 2git branch -D" [19:57:17] "git branch -D" [19:57:27] hahahaha yeah that's about to happen to Sundial attempt #1 [19:58:05] luckily there's nothing that will need to be gotten rid of in pyul -- I left all of the branch points for future reference [19:58:16] # Branch for polish addr or store codes. [19:58:17] if (popo.health & b28t30m) < 0o3000000: [19:58:17] # FIXME [19:58:18] pass [19:58:26] stuff like that [19:58:45] and the fact that that branch isn't taken is why the output from the test earlier was so weird [19:59:01] so it's really just going to be a painful relearning process [19:59:45] right [20:00:16] it does look like pass 1 is fully implemented which is good [20:00:22] so it's just a huge amount of logic in pass 2 for it [20:00:26] and I don't think pass 3 will care? [20:00:49] yeah doesn't look like it [20:39:55] mike, is there anything with pyul you need help with, I'm interested in learning more [20:50:20] oh man [20:50:37] that is a good question [20:51:24] it's probably best for me to handle the pass 2 interpreter stuff... but there's still a lot of work to be done around subroutines and revisions [20:52:06] (right now it only supports a single "main" program, and all assemblies have to be "new" assemblies because I haven't implemented any of the revision stuff or merge control cards) [20:53:13] except for a few very special cases (like the symbol table) the code is pretty much a direct python transcription of the honeywell 1800 assembly and I want to keep it that way as much as possible... so you'd have to start by learning H-1800 assembly [20:53:28] and then I can show you the general idioms I settled on for translating that into python [20:56:42] night! [20:58:12] otherwise there is transcription of the listings into punchcard format which is very tedious and I'm being extremely pedantic about full whitespace correctness in addition to a very careful proofread -- the goal is to reach 0 transcription errors at the end of this process [21:07:03] okay. hey, I've gotta run for a bit. but I'll be back later tonight. lets chat then [15:09:14] hey [15:35:40] hey guys [15:46:08] hey [15:47:29] hey Alex [15:52:00] making good progress with the LVDC update [15:55:43] hey guys [16:00:23] hey [16:00:44] good progress as in, it now builds, but is horribly broken :D [16:10:39] haha [16:10:47] glad to see its coming along thogh [16:10:52] though* [16:13:26] I made some of those scary structural changes I failed at before [16:13:52] especially the TLI restart calculations and orbital guidance, both of which are very different to the Saturn IB or don't even exist [16:16:29] one thing I might do, in the generalized flight program (Apollo 12 and later) a lot of the code is moved into modules, I might make those separate functions. The LVDC timestep right now is just one giant function with everything in it [16:16:59] even if I don't implement the scheduling logic for those modules, it probably helps keep the code a bit cleaner [16:17:34] right [16:18:25] I have fairly good information about those modules and when they would be run from the astrionics handbook for Apollo 12 [16:19:06] on the other hand, the LVDC listing that "we" have has the old program structure [16:19:20] if I actually get my hands on that I could do a lot of changes towards that [16:26:37] I wonder what happens if I try a launch right now, can't be good things [16:28:57] not as bad as I thought, it just wasn't doing any steering :D [16:37:27] morning! [16:38:57] hey Mike [16:46:57] what's up? [16:51:43] crashing some Saturn Vs [16:54:24] hehehe [17:00:52] was there any word from Ron on the LVDC code? I believe he was waiting for a lawyer to get back to him about it last time I asked [17:04:31] yeah that's still where we're at [17:04:39] lawyers are slow, especially during pandemic times [17:06:33] new Saturn V steering works through S-IC flight [17:12:41] nice! [17:13:34] just a few things to change probably then it should work through orbital insertion [17:13:46] but then it gets a bit more trick with the orbital guidance etc. [17:16:09] AlexB_88, the Saturn IB LVDC already has a state vector uplink capability, and that's luckily one of the changes I can copy & paste to the Saturn V [17:16:24] so that will be available with this update [17:19:04] Government just announced we're going back to a partial lockdown [17:19:06] great [17:20:09] I mean great to the SV update comment, not Thymo's lol [17:20:15] haha [17:20:24] Thymo, ouch, 25% daiy increase of cases??? [17:20:27] daily* [17:20:41] Netherlands goes exponential [17:20:58] Yeah, new cases are going exponentially every week [17:21:18] oh, I looked at weekly increase [17:21:32] same graphic I usually check is usually for every day [17:21:38] still bad, but not 25% in one day [17:21:45] Not a log will change for me personally. I was already working from home. I can still go to college 1 day a week to work with 2 other students. [17:21:53] s/log/lot [17:22:03] Restaurants and pubs will close though. [17:22:51] I had planned to go grab some drink with two friends tomorrow. Not sure if we should still go though. [17:23:21] for me Christmas is already cancelled [17:23:25] at least what we normally do [17:23:28] Pubs are open until 22:00 tomorrow, then they'll close for the coming 2 weeks. It'll probably be very bust with everyone wanting to go last minute [17:23:32] too many people from all around Germany [17:23:55] Yeah, Dutch people are not allowed at weihnachtsmarkten. [17:24:42] well they haven't cancelled those here yet, but I'm sure that will happen soon [17:24:47] Sinterklaas got downsized too. [17:25:05] No welcoming ceremonies [17:25:45] ah, on the 6th of December? We don't have any events for that here [17:25:54] must be a dutch tradition [17:26:11] lots of Weihnachtsmarkt though, usually at least [17:27:51] our tradition for the 6th of December is placing a shoe in a prominent position on the night before, and then in the morning a bit of chocolate has magically appeared in it [17:28:43] for children only of course :D [17:29:07] Technically his birthday is on the 6th, but we celebrate it on the 5th. Saying goes that Sinterklaas wants to be home in Spain on his birthday. Don't know the real reason it's on the 5th though. :p [17:29:33] He arrives in the 2nd or 3rd weekend of November [17:31:06] ah interesting [17:37:02] I feel like I'm missing out on a lot, being American... [17:37:25] other than COVID, of course. we've got plenty of that [17:39:46] if you ever go to Germany in December, you should visit one of these: https://en.wikipedia.org/wiki/Christmas_market [17:39:54] but I didn't know this was also a Dutch thing [17:40:57] Well I'm not sure about the rest of the country but we have them in Twente. Probably because we're close to Germany [17:41:12] I usually go to Germany though, those are better anyway. [17:41:16] yeah could be [17:41:30] Only one of those I've been to was in Philadelphia :D [17:41:33] Germans are so great with food [17:42:17] Im sure it wouldnt of compared to one in Germany though [17:43:14] every city and every small town here has them, so quality might vary :D [17:48:03] ok, making it to orbit was easy, as I thought [17:48:27] interesting difference the new steering makes [17:48:45] normally I get a small upward velocity at orbital insertion in this Apollo 11 launch scenario [17:49:06] but now I get a small, negative radial velocity [17:51:25] one issue this new steering solves is that the Saturns can have a fairly constant rate in the pitch program [17:51:51] before, the actual attitude always had to try and catch up with the desired pitch angle [17:57:34] were you able to find the issue with LM extraction? [17:58:32] ah I see something was committed related to that [17:58:55] yep [17:58:57] fixed [17:59:12] only happened when went from CSM separation to LM ejection without reloading [17:59:24] right [17:59:38] the connection between LM and S-IVB wasn't correctly established for the LM ejection signal from the CSM [17:59:54] just had to do two lines code in the reverse order [18:32:24] indy91, do you think we could merge in the OrbiterSound 5.0 branch? I have already changed the installation guide to reference it [18:36:13] yes [18:41:34] great [18:41:44] done [18:42:27] thanks [18:45:09] hmm [18:45:17] 11 succeeded, 23 failed [18:47:00] ah fun [18:48:44] what's the error messages? [18:51:45] connot open file [18:52:10] hmm [18:52:18] it shouldn't even try to use that file anymore [18:52:29] maybe I missed something [18:52:57] I wiped out my OrbiterSound4.0 from my Orbiter directory before installing 5.0 [18:53:08] makes sense [18:53:30] I probably missed some project files where it shouldn't even need the OrbiterSound40.lib [19:03:21] I guess a lot of those dont need it [19:03:31] yeah, but that confuses me a bit [19:03:56] projects like Crawler and LRV use sound functions [19:04:16] but they build fine without OrbiterSound50.lib as an additional dependency [19:06:59] which they shouldn't? Not sure [19:08:20] but for you, does it build ok? [19:08:39] well I also deleted the 4.0 lib file and got the same error [19:08:54] I'm removing that file from the project settings for each project right now [19:12:39] not even the LEM project needs it [19:19:31] it just confuses me that it wouldn't be required. It seems to build, but maybe there is something bad about deleting them [19:46:11] right [19:48:07] well I don't really know how it works, but it does link to the right .lib file even if it's not listed under additional dependencies [19:48:21] compiler definitely complains if the .lib file is missing [19:49:00] so I'll just remove all the cases in the additional dependencies, and trust in whatever is making the linking work anyway :D [19:54:54] the number of project file changes is a bit scary [19:55:24] AlexB_88, update pushed, hopefully it builds now [20:02:49] thanks [20:06:09] I'm not seeing the auto build progress on Github anymore [20:06:18] I really don't like the new design of Github... [20:11:00] and I don't think Build Bot has been made compatible with the new forum [20:11:55] hmm 1 failed [20:12:24]