[00:20:01] NASSP Logging has been started by thewonderidiot [16:47:46] morning! [17:15:45] so bad news from NARA land [17:15:52] their aperture card scanner broke [17:16:02] Ron wore it out? [17:16:08] I guess so, haha [17:16:17] he said it was starting to chug on his third day of scanning [17:16:27] ugh, are they going to get it fixed at some point? [17:16:28] it went from 2000 cards/day down to 1600 cards/day [17:16:35] and then today just wasn't working at all [17:16:49] I guess they're trying to figure out if there's something they can do or if they have to ship it out for repair [17:17:17] sadly this is their only scanner, so they won't be able to take phone orders until it's fixed either [17:17:25] The thing was made in the early 70s? [17:17:38] https://www.wwl.co.uk/wp-content/uploads/2018/11/C400-Aperture-Card-Scanner-Sell-Sheet.pdf [17:17:44] it's one of these apparently [17:22:22] hey guys [17:22:24] and these little things go for $15k so replacing it (or getting our own) is not feasible [17:22:30] hey [17:22:33] hmm [17:22:42] guess he has to find something else to scan then :P [17:22:49] haha [17:23:05] no luck for you, he left after it was determined broken, and intends to not go back until it's fixed [17:23:28] how rude [17:24:08] did you guys hear the good news? NASA is planning to build the USS Enterprise from Star Trek [17:24:17] here the first proof of concept: https://forum.nasaspaceflight.com/index.php?topic=45947.msg1928936#msg1928936 [17:24:25] Shuttle derived, of course, will make it much cheaper [17:24:51] he gets a vacation day every 2.5 weeks and it takes 1 day per box if the scanner is in full working order, and there's 47 MIT boxes [17:24:53] oh boy [17:25:16] haha that drawing is great [17:25:31] I like the solid rocket warp drive nacelles [17:26:00] yeah :D [17:26:45] crew compartment disk built by some new contractor, have to let those in on the fun as well [17:27:26] but what you are saying is that Ron already got a few 1000 new scans done [17:28:08] doesn't sound so bad to me [17:28:43] 7000 scans, yeah [17:29:12] https://archive.org/details/apertureCardBox459NARASW_images [17:29:15] https://archive.org/details/apertureCardBox460NARASW_images [17:29:34] he's going to upload the partial box 461 later today [17:30:26] 7000 pages of MSC memos would keep me busy for a year, lol. And judging by the commits from Ron in the last few months, it will keep him busy for sure. [17:30:43] there's so much stuff in here [17:30:55] among the new stuff is the assembly drawings for all (I think) of the Block II CDU modules [17:31:12] and the drawing for the CDU itself does confirm backplane wiring differences between the CM and LM CDUs [17:31:20] in addition to the missing modules [17:31:34] no schematics yet... those are in box 462 [17:32:00] well, I already that there were different CDU types functionally, haha. Everything I knew was pointing to that [17:32:06] already knew* [17:32:35] well yes, but it wasn't clear how that was manifested [17:32:48] the two could have been electrically the same but wired into the spacecraft differently for all we knew [17:33:43] it seems like the modules are all the same, it's just that the interconnections on the backplane are different [17:33:43] no [17:34:01] yeah, the interconnections are the crucial part [17:34:30] the way I understand the CDUs so far need them to be different internally, not just with the connection to the spacecraft [17:35:03] trust me, our RR CDU is basically feature complete and it does not work as a OCDU, I've tested it, haha [17:35:30] it's that read counter and error counter connection that will be different [17:35:35] probably not much else [17:36:28] the schematic in the LM Systems Handbook is pretty good [17:36:45] of course not a real drawing of it, but very detailed [17:37:08] PDF page 189/190 [17:39:04] don't think the one in the CSM Systems Handbook is as detailed, which would have been useful [17:39:18] so the full drawings should still help with understand the actual electrical differences [17:41:22] even helpful for NASSP I mean [17:41:30] I dunno, maybe I don't understand well enough, but I figured it was conceivable that the box would be the same, and the interconnections that needed to be different could be brought out to the main connector and made there -- so that the behavior becomes different depending on what cable is plugged into ti [17:41:31] obviously necessary for any more detailed understanding :D [17:41:32] *it [17:41:47] yeah, we'll get there as soon as they fix their darn scanner haha [17:42:25] my worry is that the wiring differences might only be captured on the wire list, which probably wasn't put onto aperture cards [17:42:59] that probably isn't the case, but I still worry about it haha [17:44:45] I really hope the CDU schematics are complete [17:44:53] that also worries me [17:46:45] it would help if they are complete, yes, haha [17:47:13] the 2003200+ AGC schematics turned out not to be [17:47:26] so we're lucky we had other sources for those [17:48:19] a lot of the CDU schematics got multiple drawing numbers as they were revised, so that's lucky [17:49:47] the super not detailed AOH calls the CDUs in the CSM "almost identical", haha [17:50:31] just to call them identical a few passages later [17:50:37] so I guess "almost" still applies [17:50:45] yeah [17:52:54] we'll find out sooner or later, heh [17:55:56] Apollo 11 Delco Manual, PDF page 202 shows the difference nicely [17:56:32] I just can't imagine how that would work without functional differences. Which includes backplane wiring of course [18:06:50] btw, SteveH, your simulator enclosure looks pretty great :D [18:53:47] Thanks. Still a work in progress. [17:02:09] morning! [17:04:10] hey [17:04:26] what's up? [17:05:53] just making slow progress on the launch window calculation stuff when I have time [17:06:51] same thing as always in the last 2 weeks, lol [17:07:02] haha [17:12:17] it outputs an insertion state vector now [17:12:27] which can be used for rendezvous planning before launch [17:12:35] nice :D [17:13:22] including some Shuttle specific stuff, like the sep maneuver from the external tank and dumping the rest of the propellants from the Shuttle [17:13:48] I left that part of the launch window processor class though, will make it easier to just copy&paste this into the RTCC MFD for Skylab [17:13:55] or AS-278 actually [17:14:13] I realized that the same equations in the IBM RTCC document were probably for AS-278 [17:14:38] hah [17:14:58] nice [17:15:15] seems like you keep finding reused equations :D [17:15:35] yeah [17:15:46] and even more references to memos I don't have [17:16:00] there actually is a specific one for AS-278 from late 1966 [17:16:42] "Logic and Equations for the Real-Time Computation of AS-207/208 Insertion Elements and Specialized Orbital Maneuver" 66-FM-116, Oct. 9, 1966 [17:17:00] too early for the range of memos that the archived NTRS has [17:17:25] well [17:17:28] I have about 10 from 1966 [17:17:42] at least, 10 that I have catalogued so far [17:50:03] so good news on my end -- I got the monitor boards in this weekend and got the first one soldered up [17:50:13] all of the circuits have checked out and I'll be putting an FPGA onto it tonight :D [17:50:24] https://photos.app.goo.gl/HyZNjgmc5AJuBCoS7 [17:50:37] that's it regulating "AGC" 4 volts down to 3.3 for the FPGA [18:08:16] awesome [18:14:28] Very nice! [15:04:04] hey [15:10:36] hey Alex [15:11:19] I'm in the testing stage of the initial version of the launch window processing [15:11:23] processor* [15:11:53] lots of things still to do, but for launch time and insertion inclination it would already be usable for the LVDC as well [15:20:38] I'm mostly basing this on a 1980 document for Shuttle, but the IBM RTCC document I have been using for many things also has equations for this. Probably for the AS-278 mission actually. [15:20:47] I really want to be able to do a dual launch mission... [15:27:32] Cool stuff [15:27:49] On my end I may see my 1st live launch on Sunday! [15:28:33] Falcon Heavy? [15:28:39] yeah [15:28:56] so one launch and two landings, haha [15:29:11] My girlfriend is from Cocoa Beach not far from KSC haha [15:31:08] if they stay on schedule then you have a nice show ahead of you [15:31:18] yeah, hopefully [15:31:19] the static fire was slipping a few times, hopefully that doesn't continue [15:41:32] If I remember correctly, you own a FFB joystick? [15:42:11] yes [15:42:28] Microsoft Sidewinder Force Feedback 2 [15:42:36] Ah right [15:42:44] I found one of those for cheap on ebay [15:43:31] we bought it when MSFS 2004 was released and it has endured until today, definitely can recommend it [15:43:55] DCS has some decent force feedback modelling so I bought it [15:44:15] Does Orbiter have FFB support? [15:44:56] not by default I think [15:45:06] but we aren't even using the default system for NASSP anyway [15:45:11] yeah [15:45:32] I am trying to think if there would be any point anyway to use FFB on an RHC/THC [15:45:52] yes, resistance to being moved out of detent [15:46:02] there is a specific force curve in the AOH [15:46:07] for the LM at least [15:47:00] I think the system we use would support that [15:47:08] I have thought about implementing it in the past [15:50:28] certainly would be interesting [16:50:42] morning! [17:01:04] hey Mike [17:04:08] what's up? [17:05:00] I've proceeded to the stage where I can actually do Shuttle launches in SSU to check if the launch targeting calculations are correct [17:05:42] sweet! [17:05:58] so far it's quite good. SSU doesn't do any yaw steering during the ascent, so I have to do some "calibration" of the launch time to achieve specific results [17:06:24] which are slightly different from the optimum launch time generally used for Shuttle launches [17:07:13] but the difference is just 20 seconds of launch time, so I'll try the same thing I did earlier today, just 20 seconds later [17:07:46] 20 seconds later launch with no yaw steering already gives a plane difference of about 30 ft/s, so definitely already significant [17:08:11] for the LVDC it will be no problem of course [17:08:44] :D [17:09:01] wow yeah that is more significant than I would have guessed [17:09:29] it's a tiny amount of steering it would have to do after the closed loop guidance has started [17:10:14] because the Earth in Orbiter is spherical we get the same kind of yaw error for every launch with the LVDC to the Moon [17:10:27] but 30 ft/s is only a 0.07° difference in the orbital planes [17:10:36] and that just requires a tiny amount of yaw steering [17:10:52] but becomes expensive if an orbital maneuver has to be done to correct it [17:11:57] not sure how much the spherical Earth is causing, but it wouldn't be much more than that 0.07° [17:15:04] changing your orbital plane when you are going 8 km/s is more difficult than when you haven't reached orbital speed yet, who would have thought :D [17:15:17] hahaha fair enough [17:16:32] but I am looking forward to see a Saturn IB do some significant yaw steering during an ascent when it's launching early or late in a launch window [17:17:18] the Skylab Saturn IB LVDC supported first stage yaw steering even, had a polynomial for that [17:17:45] but saturn V didn't? [17:17:56] not until the Skylab launch itself I think [17:18:03] gotcha [17:18:31] I just remembered, the EDD actually has an example polynomial taken from the Skylab launch [17:18:53] so not even for a Saturn IV, not very useful for us to use then, haha [17:18:57] Saturn IB* [17:19:09] haha [17:19:37] yeah, the EDD is from mid 1972 [17:19:47] so no final numbers yet [17:21:04] "The data in this table reflects the SL-1 Yaw Profile and is included for checkout purposes only. SL-2 data will be provided as soon as it becomes available" [17:21:07] thanks a lot, EDD [17:21:20] bastards [17:21:37] same applies to some targeting data, but in that case it doesn't matter that it's not the same rocket [17:22:45] I'm pretty sure SL-1 is always the Saturn V [17:22:54] as you will remember there is some numbering confusion... [17:23:09] yeeaaahhh [19:31:52] SteveH, I got the FPGA board integrated onto my board yesterday and everything is working: https://i.imgur.com/gSF6fJK.jpg [19:32:18] I think I've tested everything that I can without having an AGC to plug it into... so now I need to finish the board that electrically simulates the test connector [19:36:28] Great! Once you get everything settled on your end, I would be interested in talking about arranging to source / purchase the necessary boards and fpga dev kit so I can create one for my agc. [19:38:01] On an editorial note, I really dislike the security settings at work. I cannot connect to ibiblio, or imgur.com. I'm pulling up the image you sent me on my phone. :/ [19:40:25] Very nice, yeah I could create a short cable to splice that into my monitor connector :) [19:42:09] nice :D [19:42:27] https://numato.com/product/styx-zynq-7020-fpga-module [19:42:32] that's the FPGA dev board I'm using [19:42:48] with female headers [19:43:42] the one thing I found yesterday is that the LDO 3.3V output at low load is pretty spiky [19:43:48] once it gets up to 30mA or so it smooths out [19:44:25] and I think the typical operating point will be closer to 60mA-ish so hopefully it won't matter... but I'd still like to clean it up if there's an easy fix [19:44:25] Nothing that a load resistor cannot fix :) [19:44:35] haha well that would work too [19:45:20] So, the "female header on bottom" option is the correct one? (assuming your picture is showing the fpga board installed bottom side up) [19:46:04] sorry, meant female header on *top* option... [19:46:07] "female header on top" [19:46:08] yeah [19:47:06] and for programming it you need some xilinx programming cable -- I use a digilent HS-3 [19:47:07] https://store.digilentinc.com/jtag-hs3-programming-cable/ [19:54:23] night! [17:00:39] morning! [17:26:19] hey [17:26:28] hey [17:26:29] what's up? [17:27:57] planning how to lay out all the input parameters for the launch window processor [17:28:07] it's going to be at leadt 2 pages full of them [17:28:10] least* [17:30:00] hahaha oh man [17:30:55] it's a bit tedious adding so many things, haha [17:31:02] yeah I can imagine [17:31:34] and I'm already using a special library to make it easier to add new MFD pages, buttons etc. [17:31:48] without that the RTCC MFD would have been nearly impossible [17:31:52] it has like 40 pages [17:32:25] I'm only up to 7 pages with the Shuttle FDO MFD :D [17:32:32] but that's going to jump to 9 now [17:34:38] 45 pages for the RTCC MFD [17:34:41] each with 6 buttons [17:34:45] haha jeez [17:34:49] and you need to specify shortcuts for each one [17:34:56] and a descriptive text [17:35:43] and for each button there are 3 functions, if it's a button with an input box [17:36:12] each with up to 12 buttons actually, not 6. 6 on each side [17:38:09] so yeah, that's why it is tedious [17:38:57] do you think this one is going to get up to the size of the RTCC MFD eventually? :P [17:39:24] I'm not planning to [17:40:10] and I don't think it will, Apollo was more complex [17:42:16] the next big thing I could potentially do for Shuttle is the Deorbit Targeting Processor [17:42:29] in one of the documents I found there are like 250 pages on that [17:44:34] it's referencing the same JSC memo from 1976 as the FDO Console Handbook from 2007, so it probably hasn't changed much [17:45:04] the launch window and targeting stuff has changed more since then [17:46:42] oh lol [17:46:58] in working out the layout of the two input pages I forgot to add a "calculate" button [17:47:04] rather important to have that [17:47:08] hehehe [17:47:14] yep, definitely need that one [17:47:44] and also a way to cycle between pages... [17:48:10] so, uhh [17:48:13] maybe it's 3 pages [17:51:12] lol [17:51:29] 2 input pages, one page with the CLC button and the output display. So still 3 basically [20:04:12] night! [16:53:07] morning! [16:56:51] hey Mike [16:57:27] what's up? [16:58:10] got all that annoying input stuff done [16:58:29] nice! [18:08:58] SteveH, I'm pretty sure I've solved the voltage ripple problem on the regulated 3.3V [18:09:27] it seems like doubling the size of the output capacitor completely fixes it, and makes a perfectly smooth output at even no load [18:09:56] I'm getting in the bigger capacitors tonight or tomorrow hopefully so I'll be able to swap the part out and fully confirm it then [18:32:54] ...or maybe not until monday according to current tracking :( [19:05:06] ah, new AGC restoration video [19:14:36] thewonderidiot, I should have thought of the bigger cap myself. Yeah that makes a lot of sense. [19:26:32] hey SteveH, have you made any progress on uplinking yet? [19:27:20] yeah new video just went up! [19:27:21] https://www.youtube.com/watch?v=ThOXgcOOA1M&feature=youtu.be [19:27:51] all about your AGC Monitor [19:28:23] :D [19:30:00] Progress has been slow this week. I need to place an order for several miscellaneous parts including the correct d-sub pins. Will most likely work on gyro emulation software this weekend [19:31:30] Real life got in the way of progress this week. [19:31:36] I hate it when that happens :P [19:32:52] that's why my latest commit for anything Orbiter related is 17 days old [19:33:00] not just because launch windows are complicated, haha [19:34:06] Been working on some design tweaks to the master processor for my emulator. Using SPI I have only one receive thread and been working on a round-robin scheme to poll all the individual PIC processors to keep data up to date. [19:35:43] yeah that's always tricky. especially if the SPI bus gets big enough that capacitance starts to limit how fast you can talk to each of them [19:36:15] The good thing is that by modern standards, the AGC is a relatively slow computer. :D [19:36:30] hehe yeah [19:37:23] And IO updates in the milliseconds range are fast enough at the level where the SPI runs. All the higher speed bit-banging is handled by the PICs [19:37:32] it's very nice implementing all of the monitor stuff in an FPGA that has a clock 100x faster than the computer's -- I can respond as slowly as I want, debounce the inputs by waiting for a few clock cycles, and still have all the time in the world [19:37:43] yeah for sure [19:38:54] So the SPI needs to provide delta acceleration values and delta angle info, and poll all AGC discretes. things like that. Most of that stuff is only sampled by the AGC every several milliseconds. [19:39:00] a round robin scheme would also help our AGC/AGS communication in NASSP [19:39:26] to keep them in sync [19:41:50] Here's a work-in progress image of my emulator. The Raspberry Pi is the master processor that will have a QT gui touch screen interface. The cabling present is for SPI. Each PIC controller will emulate a specific peripheral (PIPA, Gyro, Port, etc). Room for 2x-3x the number of PICs currently mounted. d-sub connectors will go the the physical AGC. [19:41:53] https://drive.google.com/open?id=1gpuISBfyfeCC4rh3eGTL9EECLJR0i3ax [19:43:55] lots of stuff just for the peripherals, haha [19:45:48] Yes there is. But lots of wires to/from the physical AGC. Keeping it modular is helping. the little boards can handle a 16 bit interface, the larger board handles up to about 27 signals. Right now one little board is running uplink/downlink and another PIPA. [19:49:26] so many wires. serial interfaces were a great innovation haha [19:50:48] How many wires on the IO Mike? I forget but I know is around 200+ ish wires. I allowed for up to 300 so I can also connect physical hand controllers to the emulator [19:51:09] 360 on the main connector [19:51:24] but you probably don't care about the R circuits so that cuts out a dozen or two [19:51:31] Yeah, but I forget how many of those 360 are unique signals. [19:51:44] 18 are power/ground [19:51:47] and I'm running single-ended digital interfaces [19:51:51] oh yes [19:51:58] many of these are transformer-coupled pairs [19:52:05] you're definitely good [19:52:29] I *did* count them all a while ago but just purged that unpleasant memory [19:52:33] hahaha [19:52:42] that's one of my tasks for this weekend actually [19:53:01] I'm going to put together a table that maps the alphanumeric designator for each wire to the internal net name in the AGC [19:53:17] to have it document that, for example, D-207 is SBYBUT [19:53:27] *documented [19:53:52] and then I'm going to color in every pin on the backplane viewer based on what subsystem it's used for [19:54:03] I have something similar in my netlist I generated for my AGC. Placed all the module connectors on a single schematic, resolved any naming mis-matches and that's what I used for the wire-wrap netlist [19:54:04] so we have a good idea of how wires are grouped for building harnesses [19:54:10] and I thought the I/O schematic in the LM Systems Handbook had many connections... [19:55:07] but it's the same numbers from there, right? [19:55:18] so your 207 is "Enable STBY to DSKY" [19:55:44] no, different numbers [19:56:00] the LM-8 systems handbook has actual pin numbers [19:56:21] the designators are unique codes throughout the whole PGNCS [19:56:21] I only remembered that you found those numbers useful, haha [19:56:41] so D-207 is on AGC main connector pin 502, for example [19:56:45] no correlation between the numbers [19:56:58] and yes, that discovery of yours is the reason why this whole restoration thing started haha [19:57:19] what a weird sequence of events [20:00:10] but it was you who discovered that the JSC History Collection is rather useful for our purposes :D [20:00:22] hehehe [20:00:53] my jaw just about hit the floor when you gave me that pin number without realizing it, haha [20:01:07] that was one of the things I had been searching the hardest for for a couple years at that point [20:46:23] night! [17:03:04] good evening [17:05:22] morning! [17:08:00] hey [17:08:11] checklists! [17:08:29] AFJ uploaded scans of two of the Apollo 11 checklists from the Smithsonian [17:09:04] Launch checklist and Operations Checklist, which is G&C and Systems Checklist combined [17:09:18] and I sent David Woods an email and asked if there is more to come :D [17:09:31] oh!! nice :D [17:09:33] the one with the backup erasable load is the Alternate & Contingency Checklist [17:09:38] that's the one Ryan asked them about [17:09:44] that is awesome! [17:10:00] currently making PDFs from the pictures of the individual pages [17:31:03] for the longest time we didn't have any CSM G&C Checklist from before Apollo 15 [17:31:21] the Apollo 8 one is very similar to 11 of course [17:31:26] but there is still some unique stuff [17:36:02] same in the launch checklist. TD&E procedure is slightly different (almost on every mission) and indeed there is no way yet for the CMC to start the TLI events in the LVDC [17:36:20] Apollo 12 already had an erasable memory program for that [17:36:29] apparently doesn't work yet in Comanche 055 [17:38:02] oh interesting [17:39:30] probably just had to reorganize some erasable memory variables so that they could load an EMP like that [17:39:44] other than that there wouldn't really be anything in software that prevents it [17:39:57] but the one from the Apollo 12 padload definitely doesn't work in Comanche 055 [17:40:17] well hopefully we'll be able to dump comanche 67 and find out what exactly changed :D [17:40:42] and use that EMP [17:40:57] on the other hand, the CMC takeover during boost was already working [17:41:12] so the hardware connections were all working [17:41:16] between CMC and IU [17:41:33] hmm [17:41:44] so we might be able to change the EMP slightly to make it work if we really wanted to [17:42:14] yeah, that might be possible [17:42:49] all it really does is set an output bit at the right time [17:43:17] do we have the code for the EMP or just the octal? [17:44:31] Data Book has just the octal [17:45:23] fun :D [17:45:44] maybe I'll try fixing it after I go get some food [17:46:21] yeah, you give it the TB6 time from the TLI PAD and it then automatically sends the output bit at the schedule time [17:46:38] the Apollo 12 checklist has the even more manual procedure to just set the output bit yourself [17:47:04] and of course the procedure to start the EMP [17:47:25] might be difficult to fix when you don't know the erasable memory locations it is referencing [17:48:26] the Apollo 11 backup procedures still need the LVDC to be able to determine the TB6 start time itself [17:48:52] which basically means the LVDC is working at least 99% correctly [17:49:04] could be useful if the FCC is broken or so [17:49:10] no [17:49:12] half broken [17:49:27] it would be CMC -> FCC commands, just via a different channel [18:24:38] yeah, will have to see how bad it is [18:24:46] my guess is that whatever it's referencing probably didn't move too far [18:31:11] hmm [18:31:19] so this EMP is somewhere in the CSM data book? [18:31:41] the 1969 one [18:32:00] HSI-208962 [18:32:09] PDF page 799 [18:32:16] it's all called "TB6JOB" [18:32:34] and the procedure to use it is here: https://history.nasa.gov/afj/ap12fj/pdf/a12_l_o_c.pdf [18:32:45] PDF page 43 [18:33:50] oh cool, that's simple [18:34:50] oh, and I guess a countdown to TB6 is also part of it, judging by the procedure [18:35:04] "F 06 45 Time froM TB6" [18:35:08] 34* [18:47:19] remember this? https://history.nasa.gov/afj/ap11fj/a11csmoc/a11-csmoc-f4-13.jpg [18:48:40] hmmmm, no? [18:49:00] P38 [18:49:04] stable orbit rendezvous program [18:49:19] I taught you how to use it when you were waiting for a flight or so [18:49:27] with the standalone Virtual AGC [18:50:04] oh! yes :D [18:50:18] Apollo 11 CMC still had it, was deleted afterwards [18:50:28] just like P17, TPI Search [18:52:53] making space for, no idea [18:53:14] hehe [18:53:28] well I am almost done disassembling this [18:53:33] and it is very obviously broken lol [18:55:17] modifies memory it really shouldn't modify? :D [18:56:07] it caluclates a time and then transfers control to NEWMODEA... to set the major mode to that time??? [18:56:16] lol [18:56:33] two digit time display, super useful [18:57:18] oh btw, my favourite thing from the latest AGC video is when you made a digit display || instead of 0 [18:57:34] didn't even know you could do that [18:58:45] hehehe [18:58:58] yeah the relay decoding can lead to some weird "digits" [18:59:24] the proper software just doesn't have any way for you to give the DSKY something bad :D [18:59:35] yeah [18:59:44] you could display things like: HELP [19:00:01] sadly you can't make a lot of letters [19:00:03] to randomly freak out some astronauts [19:00:17]