[19:56:19] NASSP Logging has been started by indy91 [19:56:27] wasn't even on [21:23:27] night! [18:48:08] morning! [18:54:13] hey [18:59:19] what's up? [19:02:48] went through old Orbiter folders today, somehow nothing I have worked on in the past is working anymore [19:03:00] none of the unfinished projects that is [19:03:09] hahahaha [19:03:19] that's strange [19:03:34] it probably went like this: it was working at some point, I tried to do an update, didn't work, got frustrated, abandoned project [19:03:57] so some small fix would probably do it, but after some years, no clue :D [19:06:08] my Delta Glider Autopilot thing can still automatically fly a traffic pattern at the Shuttle Landing Facility at least [19:06:15] but ascent to orbit is broken, lol [19:06:30] based on LGC ascent guidance actually [19:07:32] not bad for 2013 Niklas [19:09:47] hahahaha oh man [19:10:00] those are some old projects [19:11:29] yes [19:11:35] I never throw anything away [19:11:47] there was a very difficult to set up Orbiter addon [19:11:58] called STS Payloads, had a bunch of payloads for the Shuttle [19:12:14] and to this day I still have a separate Orbiter install saved for it [19:12:24] on the external hard drive by now, but still [19:12:26] Orbiter 2006 [19:12:52] let's see when I did that... [19:13:15] wow [19:13:57] difficult to say [19:14:01] pre 2010 [19:14:45] none of the installed addons are from 2009 or later [19:15:21] the change date on the folders is definitely when I got my laptop for university [19:16:02] Orbiter exe crashed almost immediately [19:16:13] so much for a "working install" [19:16:24] maybe with Windows XP :D [19:18:04] hahaha [19:18:08] compatibility mode maybe? [19:20:25] hmm, I think there is some edit protection on the folder [19:20:36] Orbiter Sound didn't like it, now I am one step further [19:22:14] Orbiter 2006 loading screen, long time no see [19:22:49] oh man [19:24:39] it works! [19:24:55] had to give me full write/read access to the folder on the external drive [19:25:15] wow [19:25:17] impressive :D [19:30:20] can't really figure out how to launch, but it basically works [19:33:14] lots of old Shuttle scenarios, one of the Shuttle addons for Orbiter is not available anymore, so this might be a good way to get accurate ISS TLEs [19:33:19] for various missions [19:33:39] oh nice [19:34:01] yeah, the scenarios were created with great care taken for accuracy [19:36:38] I'm surprised I don't have an old NASSP install [20:57:39] night! [06:51:45] thewonderidiot, still awake? [06:51:57] I am! [06:51:59] what's up? [06:52:23] first, good morning! [06:52:24] haha [06:52:30] good morning! [06:52:35] this sounds like something for you: https://www.orbiter-forum.com/showthread.php?t=40579 [06:53:01] oh yes, I can definitely take that one [06:53:15] thanks for pointing it out :D [06:53:29] no problem [06:56:24] AGC addressing is pretty rough, heh [06:57:08] I was working on something related to it the other day... I don't remember what [06:57:22] but the rationale for how the superbank bits work finally clicked [06:57:23] we talked about Sunburst avoiding some memory areas [06:57:26] I get it now [06:57:36] before that, this was a few weeks ago [06:58:03] well, if you understood something new about the AGC in 2019 then it must be rough indeed [06:58:35] the problem was just that there are 3 superbank bits, but the original documentation all only talks about one of them [06:59:52] which doesn't matter if you're only dealing with the 36k available from fixed memory [07:00:11] but do matter if you want to take advantage of the full 64k of address space that the three superbank bits give you [07:00:46] this was when I was working out linear address decoding in the monitor [07:00:55] ah, I see [07:01:48] once I got that, the rest of the addressing scheme became super clear [07:02:01] I might have to make some diagrams, since none of the original ones fully capture it [07:04:57] also, I have a new thing to get drawings of on Monday [07:05:19] this will be our first North American drawing from NARA, if they have it [07:05:50] oh [07:06:58] what is it? [07:10:47] https://www.rrauction.com/preview_itemdetail.cfm?IN=5094 [07:10:50] this thing [07:11:02] ME 901-0666 fits within one of the boxes they have [07:11:09] and I have no idea what this thing is [07:11:13] and I want to know what it did :D [07:11:57] ah right, I remember this [07:12:51] " The Computer Buffer Unit was part of a system of pre-flight ground check out equipment to confirm the Apollo Guidance Computer (AGC) was fully operational for the lunar mission." [07:13:38] yes, but what exactly does it do [07:13:44] what signals go through it? clearly not all of them [07:13:49] those connectors aren't big enough, haha [07:29:52] alright, answered [07:30:24] it's too late for me to diagram up how I think about addressing so I'll do that tomorrow or something [07:31:18] haha, I'm sure the answer is adequate [07:31:22] I forgot how many errors are in that book :/ [07:31:47] I remember being similarly confused when I read it [07:51:29] I reworked the monitor board mechanical design today [07:51:41] still needs some signal rerouting but it looks much better [07:52:30] nice [07:52:33] it's all starting to come together: https://imgur.com/a/DtJCURY [08:03:40] yeah, looks quite good [08:08:16] thanks :D [08:35:28] currently tempted very much to get a MSC memo called "Skylab Launch Window Processor" from NARA [17:36:53] indy91: sounds pretty relevant to what you're working on. any idea how big it is? [17:38:25] also, good morning! [17:38:39] hey [17:38:42] no, no idea [18:16:55] that document was already on my list of MSC memos to scan at NARA [18:17:01] just quite down the list [18:19:06] if it is good then it has many pages [18:19:11] too many pages, haha [18:37:13] hehehe [18:38:00] the paradox of text documents at NARA [18:38:07] everything worth requesting... is not worth requesting [18:38:17] yep [18:39:09] best I can do is to keep the list updated, if Ron gets bored or has some time between scanning AGC schematics [18:39:21] yep [18:39:27] kind of how it worked out last time [18:39:44] at least that is what he said, that he had time between getting AGC schematic boxes [18:39:49] or if I ever actually take my trip there... [18:42:16] so for the 50th anniversary of Skylab [18:42:40] hehehe [00:21:46] hey, thewonderidiot [01:10:01] hey SteveH! [01:10:02] what's up? [01:10:52] I took about a week or so off from my project but put some time in today and got the PIPA emulator working. Made my PIPAFL light go out :) [01:11:14] nice! :D [01:11:21] that's awesome! [01:11:28] https://drive.google.com/open?id=1zwokaCMlV2YN4GEYrnfimAr55wRlV8aG [01:11:56] https://drive.google.com/open?id=1dnbBoEpL_6C9n2fYogqA9g6NzgUy3vad [01:12:27] beautiful [01:12:37] can it inject accelerations too? [01:12:39] The last link is a shot of the AGC monitoring the PIPA counters while I increment and decrement them via the gui [01:12:54] oh cool [01:13:00] Yes, I can manipulate the PIPA counters at will now. [01:13:51] sweet [01:13:55] so what's next on the plate now? [01:14:02] I transmit a delta to either a + or - register via SPI and the pulse train is modified to send the proper number of +/- pulses while mainting the +/- 3 "zero"value [01:14:19] Going to get the IMU CDU pulses working [01:15:09] Those will be one-shot timers triggered by the CDU strobes from the AGC [01:15:46] is there a CDU strobe output? [01:16:12] I vaguely remember a CDU clock output, but I think it's at a higher frequency than the pulses, isn't it? [01:17:47] ah, there is a CDU strobe, but it doesn't hit the main connector. guess it's only for internal gating? [01:18:18] I need to go back to the documentation, it's been a while. I thought the CDU pulses were variable duration based on angle and synced with a signal to the AGC, I could be wrong [01:18:56] I could also be confusing the radar interface with the IMU interface. Lot's of similar schemes with slight variations each [01:19:38] we really need to get a full set of CDU schematics, heh [01:19:54] yeah CDUSTB/ controls PINC/MINC/DINC generation internally [01:21:04] There's more than enough info in the available documents, the fun part is that every peripheral has a slightly different interface. Some are counting pulses, some are counting pulse width, and the pulse width counters are sometimes synched to a strobe line and sometimes free running. :) [01:21:49] I always found the CDU to be particularly confusing [01:22:03] because (I think) the maximum pulse rate coming out of the CDU is 6400pps [01:22:09] per channel [01:22:40] but the clock output to the CDU is 51.2kHz [01:22:55] Yeah, I backed into understanding the PIPA pulse trains, now I need to refresh what I've already forgotten about the CDUs [01:22:57] and I never found a clear answer for how the pulses are rate limited or aligned to that clock [01:24:02] I was running the PIPAs at +/- 4G on the LM for fun today.... [01:24:29] hehehe [01:24:59] I need to assemble the chassis for these HW emulators so I can get them all running at the same time. I currently only have the one board active so I disconnected the hook-up for upload/download to work on PIPA [01:25:25] Have all the parts, but it's been too cold in my garage to work on the sheet metal. [01:25:28] ah yeah [01:25:29] heh [01:26:24] I've been making solid progress on the monitor design. should be able to finish routing the PCB tonight: https://i.imgur.com/AtlQ4x4.png [01:26:29] I saw the latest video about the erasable memory module. Were you traveling for that one? [01:26:58] nah, the computer history museum is just down the road [01:27:45] here's the full monitor assembly: https://cad.onshape.com/documents/92cad92555e98e88fa5f5e38/w/0e5bae8ff640d26b83a1661a/e/e602bb611d754797fce920b7 [01:28:01] the first tab on the bottom (2003074) shows it plugged into tray A [01:28:08] Nice clean layout, that should work. Very convenient about the museum. Not much of that sort of thing in the Rochester, NY area... [01:29:14] how far away is the Cradle of Aviation museum from you? [01:32:00] about 360 miles to long island. I'm on the other end of the state. [01:32:09] ah damn [01:33:37] Yeah, NY state is about 400 - 450 miles wide. I'm over on the western side of the state right below the middle of lake Ontario [01:33:46] gotcha [01:34:37] I've heard rumblings that Grumman's set of aperture cards may have been transferred there, which could help in filling in the gaps missing from NARA Ft Worth [01:35:04] Interesting. [01:39:47] I gotta go but I'll be digging into the IMU CDU signals this week. I'll let ya know how it goes. [01:40:03] sounds good, looking forward to hearing about it :D [14:42:30] @indy91 good morning [14:42:37] hey [18:09:47] morning! [18:11:29] Hey [18:12:50] hey guys [18:16:31] what's up? [18:24:27] just putting another release of my Shuttle FDO MFD together. Just a few smaller updates. [20:22:13] I guess Don Eyles no longer has his DSKY [20:26:23] oh? what makes you say that? [20:26:37] it's up for auction [20:26:44] https://rrauction.com/preview_itemdetail.cfm?IN=5222 [20:26:50] unless he has more than one [20:26:56] "He retained the DSKY in 1978 when the LM cockpit simulator was dismantled and discarded. [20:26:57] " [20:27:12] hmm [20:27:17] maybe I read that wrong [20:27:26] it mentions Don a bunch of times, but doesn't say that he is the owne [20:27:28] owner [20:27:35] "the present owner, who was employed at the MIT Instrumentation Laboratory to design, build, and maintain the CM and LM cockpit simulators" [20:27:43] yeah, Don just grabbed a random DSKY [20:27:51] this one belongs to the guy who made the simulators [20:27:51] as you do [20:28:06] yeah, read that wrong. [20:28:15] I'm curious to see how high this gets [20:28:24] https://rrauction.com/preview_itemdetail.cfm?IN=5103 [20:28:28] this confuses me [20:28:29] I would love to have a DSKY... [20:28:45] it has a "HI GAIN ANT SCAN LIMIT" light [20:29:01] apparently manufactured in June 1969 [20:29:21] but I thought they had abandoned that light even before Apollo 7 [20:29:37] is it block I? [20:29:42] June 1969 [20:29:56] and it says Block II [20:30:10] so, we have an early CSM-101 Systems Handbook with that light [20:30:15] and the NASSP panels originally had it [20:30:27] then I figured out how the light would work and it would be on very often [20:30:37] well the auction says block II, but they can and have been wrong [20:30:41] and I did the research and thought I figured out it was not flown [20:30:55] 99% sure it's Block II [20:30:58] but june 69 is probably too late for that heh [20:30:58] yeah [20:31:06] looks exactly like in the CSM-101 Systems Handbook [20:31:54] ah nice [20:32:02] whoops, wrong window [20:32:09] do the later handbooks not show it? [20:32:13] nope [20:32:20] but we don't have any intermediate ones [20:32:29] next one is Apollo 15 or so [20:32:32] ahh [20:32:38] just, I thought this light wasn't even flown on Apollo 7 [20:32:40] or any mission [20:32:52] so, why make this in June 69 then [20:33:03] maybe the light was there, but not connected, so it never lit? [20:33:09] yeah, possible [20:36:00] CSM-101 and 104 [20:36:05] Systems Handbooks [20:37:03] COMMAND SERVICE MODULE SYSTEMS HANDBOOK CSM 108 ( COMMAND SERVICE MODULE 108 ) THROUGH CSM 111 [20:37:09] we don't have that, right? [20:38:40] don't think so [20:39:47] maybe worth adding to the next request from Lauren then [20:40:39] I forgot Smithsonian scanned their Apollo 11 CM in 3D [20:40:52] oh! they did [20:40:58] I forgot about that too [20:41:20] light is not there [20:41:33] but it almost looks like it was removed at some point [20:41:41] huh [20:41:44] it's different from the other blank ones [20:41:50] surely before the mission though [20:41:59] or maybe even covered up [20:42:14] I doubt it would be connected [20:43:10] sounds like that's probably it then [20:43:27] I guess it was decided, why bother changing the design if you can just cover up the light and not hook it up [20:43:36] could be [20:43:48] you run into the scan limit so many times [20:44:05] Apollo 13 had an issue with their HGA where it would cycle back and forth [20:44:19] the repeating alarms would be more annoying than the explosion [20:47:11] oh! [20:47:21] Apollo 8 technical debriefing [20:47:31] The only caution and warning lights that we [20:47:32] had on the entire flight was the high-gain [20:47:32] scan limit, the 0 2 high-rate during water [20:47:33] dump, and the fuel cell 2 during 0 2 purge, [20:47:33] and one crew alert light that worked quite [20:47:34] well. [20:48:01] so I guess Apollo 8 had the light and probably functional [20:50:48] oh interesting [20:54:05] http://www.collectspace.com/review/rickmulheirn/apollo10_cm03.jpg [20:54:07] Apollo 10 [20:54:15] terrible photo, but it looks the same as Apollo 11 [20:54:24] a dark spot where the light would have been [20:58:48] https://www.flickr.com/photos/projectapolloarchive/21315590814/in/album-72157659042210300/ [20:59:08] almost not to see [20:59:11] but I think it's there [20:59:21] if functional or not is another story [21:02:34] oh man, that is some fine detail scouring haha [21:03:11] seems likely that if it was not covered in 9, then it would still have been connected [21:03:13] it helps if you know what you are looking for :D [21:04:54] haha true [21:06:55] a bunch of text that barely fits on a single light [21:23:35] haha yeah that does make it stand out [21:23:52] curious that they didn't decide to abbreviate it to HGA or something to make it fit better [21:31:36] still haven't heard back from NARA on whether they have a drawing for that computer buffer thing [21:35:37] NARA is still buffering I guess [21:35:39] try a refresh [21:40:12] hopefully it's because they're too busy processing Ron's application :P [21:49:43] sure [22:07:07] night! [17:05:50] morning! [17:18:33] Hi Everybody [17:18:42] First time on the IRC [17:21:39] hello, welcome! [17:23:26] I have a few questions. I know a little bit of C++ and have been messing around with NASSP for a few years, but never got in contact. After posting about the MCC issue for SV update on the forum I wondered if there is any need for basic code cleanup and documentation for the 8.0 release [17:24:06] code cleanup is probably something that NASSP can always use, haha [17:24:32] and documentation as well, in this stage of NASSP 8.0 [17:25:43] I've also seen your issue on Github [17:25:50] during FC purging [17:26:17] I've seen that before as well, didn't get to researching that yet [17:27:17] II finally got around to doing a full apollo 7 using the orbiter2016 branch so im making sure to document any weirdness possibly from the transition to the orbiter beta. [17:28:57] II have been looking into editing the label.tree file for earth to get the AGC landmarks working right. [17:29:34] IIt doesn't seem too difficult using available tools. The only difficulty will be sorting the landmarks onto the proper tiles [17:30:27] yeah, I think we will have to edit that file [17:30:38] I dislike it when we have to overwrite a default Orbiter file [17:30:47] but I think we don't really have a choice [17:33:16] I'm almost suprised that the P27 PAD was the first big issue with the MCC on Apollo 7 [17:33:36] I made a lot of changes to the MCC and hadn't tested Apollo 7 or 8 so far with it [17:34:13] II was able to activate the legacy .mkr files. They seemed to work ok for my purposes using the data from the Apollo 7 Update Forms document [17:34:51] As far as I can tell the MCC seemed to work perfect except for that P27 issue which appears fixed [17:35:02] good [17:35:19] yeah, it definitely was broken. There was some special code that got removed for "generic" P27 PADs [17:35:39] I am confused about the entry procedure though. The checklist was confusing and I couldn't find much info. [17:35:58] Is there a manual control test before CMC takeover? [17:37:11] I looked for mission documentation about how the crew did the entry [17:38:03] the checklist might need some improvements, could be [17:38:19] nothing Orbiter 2016 or NASSP 8 specific though, just in general [17:38:48] I think I did the Apollo 7 checklists, but haven't looked at that since the NASSP 7 release [17:38:52] most of* [17:39:13] there definitely is a bit of time before giving control to the CMC [17:40:26] first part is flown manually, until after 0.05G [17:44:02] I'll be back in a bit [17:45:23] hi tcirre93_! [18:01:06] Hi! [18:01:29] Any tips on flying the apollo 7 Entry? [18:11:37] back [18:12:16] which part exactly? [18:14:27] manual up to P67, then a check if the downrange error value is within the limit (100 NM) and then you can give control to the CMC [18:27:46] In the checklist it says to fly the lift vector until the 0.2 G time. Is this the transition point to automatic mode [18:29:16] lift vector up that probably means, right? [18:29:53] I think the transition is still a little bit later [18:30:05] first you would roll to 55° left or right [18:30:11] that's the Backup Bank Angle (BBA) [18:30:43] if you are in daylight you could even look through the upper hatch, it has markings for that 55° angle [18:31:20] and then after the manual roll and after the CMC has transitioned to P67, then you give it control [18:31:34] I think that's how it was supposed to work [18:32:06] if I remember correctly the actual mission kept it under manual control for a while longer, but that's pretty much crew preference [18:33:57] or just fly it manually all the way using the error needles (so CMC guidance, but not control) [18:47:14] indy91, sadly no luck on the rope jumper modules, but they did find 8 cards for ME901-0666, so hopefully it will have some answers about what that thing is [18:56:45] the buffer [18:57:58] so you need to do some guessing with the rope jumper then [19:23:45] San Diego Air and Space Museum has some Apollo 9 checklist that they photographed and put on Flickr [19:25:57] hmm [19:26:25] LM Rendezvous Activation Checklist. That is privately owned, I have contacted the owner, who sent me a few photos [19:26:33] these are the same photos, same blue background [19:27:43] it's lower quality, but probably all pages [19:34:30] oh nice! [19:36:18] I wonder if they put this anywhere else in better quality [19:36:50] link? [19:37:52] https://www.flickr.com/photos/sdasmarchives/albums/72157705290322601 [19:38:01] all pages there [19:38:25] oh yeah that is very small [19:38:49] all readable I think [19:38:55] which is the important part [19:39:03] they were purportedly taken with a DSLR, so there must be much better versions somewhere [19:39:34] I know that they exist, because I have them [19:39:36] a few pages [19:39:39] the owner sent them to me [19:39:42] ah, right [19:40:30] 900x598 versus 4288x2848 in one example [19:45:52] very nice to have the complete one [19:46:03] now we just need the other two Apollo 9 LM Activation Checklists :D [19:46:29] well, more like 2.5, the EVA Checklist only activates a very limited number of systems [19:47:30] I hope the Smithsonian releases scans of all their Apollo 11 checklists for the anniversary [19:47:34] that would be nice [19:11:05] afternoon [19:14:15] hey [19:14:50] what's up? [19:15:49] NARA is frustrating me haha [19:16:20] the archivist that did the last scan for me still hasn't picked up the phone to take payment information [19:16:29] I really wish this system wasn't so antiquated [19:18:34] investing money in a good system would appear as wasting taxpayer money. Or something like that :D [19:18:42] yeah, yeah [19:19:03] much better to waste taxpayer time :D [19:19:10] lol [19:21:33] In Germany it would be a much better system, just with 12 separate steps and 23 forms to fill out [19:21:49] hahaha [19:21:55] okay I appreciate that it's not that then :D [19:23:23] so you are getting drawings of that buffer thing then [19:24:13] yeah, 12 cards [19:26:21] I still have to go through the Apollo 9 rendezvous activation checklist [19:27:08] one interesting thing is the part for the ascent stage burn to depletion [19:27:47] it has two separate "opportunities", with different TIG and DV [19:28:23] which probably means insertion into a specific orbital plane [19:28:31] two different burn to depletions, with different DVs? [19:28:45] yeah [19:29:00] so in one of the cases more fuel has already been expended or something? [19:29:25] no, I think the target orbit is the same [19:29:53] mainly the out-of-plane component is different [19:30:39] so the two TIGs are probably two intersections with the specific target orbit plane [19:32:04] will have been updated in real time of course [19:32:54] if things take longer than expected it simply provides a second opportunity for that orbit [19:36:17] that checklist covers everything in the LM for the activation on rendezvous day and the picks up after redocking [19:37:00] Apollo 9 had a lot of checklists [19:38:20] Apollo 5 left a lot to be desired and tested:D [19:41:16] hahaha [19:41:23] but that made it so much more fun to us to figure out! [19:53:11] yeah [20:58:40] night! [17:05:48] morning! [17:14:02] hey Mike [17:14:07] hey [17:14:08] what's up? [17:14:48] adding more MSC memos to my NARA list... [17:15:06] hehe [17:15:32] they actually picked up the phone for me this morning so hopefully I'll be getting that drawing today :D [17:16:31] oh, great [17:17:13] hopefully I don't have to drill too far down in to child drawings to figure out what it was used for [17:19:34] we know it was GSE, right? [17:19:46] we know that it was GSE, and interfaced with the AGC for some purpose [17:20:28] ground equipment could still be many things. Might not even be on the mobile launcher [17:21:03] I'm hoping it was more a lab test kind of thing... and wondering if it might still be useful to use with AGCs [17:21:27] yeah, probably lab [17:22:25] the MSC memo I currently want is from Skylab again, but it's kind of a middle thing between Apollo and Shuttle [17:22:54] in fact, I believe I found a routine for LM lunar launch window targeting that was reused in some fashion for Skylab and then Shuttle and used through the end of the Shuttle program [17:23:28] variable names on the input screen give it away [17:23:58] hahahaha, nice! [17:24:13] you are probably the only person who ever could have noticed that, lol [17:24:23] who didn't work on it at least [17:24:36] well, I just followed the trail of references, haah [17:24:37] haha [17:24:46] one of the missing Apollo memos almost has the same name as one we have, but it's different [17:25:09] and it's not based on the other one, often you get superseding memos [17:26:48] "Logic and Equations for the real-time computation of the LM launch window and recommended lift-off time" is one we have [17:27:12] "Logic and Equations for the real-time computation of the LM launch targeting and display" we don't have [17:27:30] and those documents definitely existed in parallel [17:28:12] I think the former might be more concerned with the rendezvous and assumes the P12 inputs as constant [17:28:25] and the second one is for calculating those insertion parameters for P12 [17:28:28] maybe [17:28:58] both of these are quoted in 1980s Shuttle launch window targeting [17:29:35] hmm [17:29:42] sounds reasonable [17:29:50] also sounds confusing, those names are super similar [17:30:02] yeah [17:30:21] the one we have is memo 69-FM-31, based on memo 68-FM-5 [17:30:31] and the one we don't have is 68-FM-67 [17:31:16] we also do not have the update to 69-FM-31, which is for the Apollo 14+ short rendezvous profile [17:31:40] there doesn't seem to be an updated version of 68-FM-67, which is interesting [17:31:53] must mean the logic in there wasn't really changed throughout the program [17:32:17] how do you follow these chains of memos? this doesn't sound like something that would have been written down anywhere [17:33:44] only written down on the title page, lol [17:35:15] oh wow, NARA might not even have 69-FM-31 [17:35:17] NTRS had [17:35:26] wanted to give you an example [17:35:40] basically, 69-FM-31 says on the title page [17:36:01] "This revision supersedes Internal Note No. 68-FM-5 dated January 5, 1968" [17:36:20] I see [17:36:36] but you don't necessarily know if an earlier memo has been superseded unless you find one that supersedes it? [17:41:13] yeah [17:41:25] https://archive.org/details/NARASWSelectedApolloBoxe [17:41:30] I'm just looking through this [17:41:33] https://archive.org/details/NARASWSelectedApolloBoxes [17:41:47] search function is usually reliable [17:46:30] so it's lucky this information is on the title page, since that's all Ron scanned, haha [17:47:01] not always on the title page, but yes, haha [17:47:51] https://archive.org/details/NARASWSelectedApolloBoxes/page/n725 [17:48:09] the document for Apollo 14 and later has a slightly different title [17:48:38] I guess it doesn't really supersede the earlier document, because the concentric rendezvous profile was still the backup and needed to still be possible [17:48:56] so this would just be an addition [17:49:13] but the title is clear, it's the same document, just additional features [17:50:19] and I am fairly sure I solved the short rendezvous profile without even having that document [17:50:35] it doesn't really allow for a launch window anyway, haha [17:51:06] if you haven't had liftoff after a few seconds you need to wait until the next rev [17:59:23] ah, got the drawing! [17:59:39] unsurprisingly it is a specification control drawing, since the thing was built by motorola [18:00:54] first made in late '64 so it's applicable to block I [18:02:06] doesn't explicitly say what the thing was for but it does have a pinout for all of the connectors [18:03:35] J202 is differential "1" and "0" output lines, so that must go into the AGC [18:03:45] on one of the serial interfaces [18:03:52] J200 is power [18:04:40] J203 is the big connector... 18 differential bit inputs, "G&N Select", "Group Decode Check", "Buffer Not Busy", "Mode Check", "Buffer Check" [18:04:45] what's 18 bits in the AGC? [18:05:18] my guess is that this is an uplink serializer... takes parallel data for uplink and converts it into the serial 0 and 1 pulse train [18:05:20] uhh [18:05:36] but not sure why 18 bits [18:06:00] yeah, 18 is weird [18:06:27] AGS is 18 bits, but this is a North American thing so there's no reason they would have been talking to an AGS [18:10:15] is the thing Block I specific or for both Blocks [18:10:27] great question [18:10:38] I don't know enough about Block I serial inputs [18:10:48] so I have some ND-1021041 reading to do tonight [18:13:50] if it's block II it can only be uplink or VHF [18:14:06] those are the only things with "0" and "1" pulse inputs to the computer [18:14:17] or the GDC [18:14:34] hmm? [18:14:59] BMAGX to Z [18:15:03] or is that not 0/1 pulses [18:15:19] nah, those are plus and minus pulses [18:15:22] ah, ok [18:17:04] VHF would still not be 18 bits of course [18:17:14] yeah [18:18:01] could also mean that the total output of a system is buffered [18:18:09] so e.g. 15 bit word and 3 output bits or so [18:18:33] there's no pins for that though [18:18:38] ah, ok [18:29:58] uplink looks pretty much the same in Block I as it is in Block II [18:35:32] one thing they got right with Block I :D [18:36:21] hehehe [18:38:41] yeah, confirmed it's identical [18:38:43] now what about radar [18:39:32] seems like it wasn't used [18:39:37] Hey, just saw this thread. Radar is also a pulse width measurment interface [18:40:39] uplink is 16 bits, not sure what an additional 2 bits would be used for [18:41:04] yeah. it's looking like the radar interface in block I behaved the same way [18:42:24] yeah [18:42:25] hm [18:42:29] 2 extra bits, how strange [18:42:45] do you agree with my general assessment though, given that SCD? [18:43:02] There's a start bit as the MSB that is always '1' and forces an overflow triggering the uprupt, followed byt 15 bits of data [18:43:28] yeah, looks like parallel to serial is the best guess I have [18:45:45] yep [18:49:19] The G&N select signal is the one thing that looks out of place. Guidance and Nav select mode switch has nothing to do with parallel to serial....??? [18:50:43] I see "Computer Buffer Unit Guidance and Navigation" in title block of drawing [19:01:36] hey Steve [19:03:43] yeah, that's pretty much all we know about it, haha [19:03:53] some sort of North American GSE used presumably with the AGC [19:06:39] and this drawing really doesn't reference any other drawings that may have answers, heh [19:12:17] other than maybe the procurement spec [19:12:58] MC 901-0666 [19:13:06] that could possibly be in box 383 [19:50:28] Not the same exact box, but similar: https://www.icollector.com/item.aspx?i=31389156 [19:50:53] yeah, with a different part number [19:50:58] maybe I should get the drawing for that one too [19:51:33] that one has two part numbers even [19:51:48] ME901-0271 and ME476-0070 [19:52:42] the ME476 one is less likely to be at NARA but could be in box 399 [19:53:09] ME901-0271 is almost certainly there [19:53:29] alright, so I've got three drawings to request on Monday [19:53:43] that will maybe hopefully have more info [19:55:02] Or each of those three will lead to another three... :) [19:55:07] hehehe [01:01:17] hello [01:01:25] hi Copenhagen_Bram! [01:01:30] welcome to the channel :D [01:04:18] There's no virtual AGC mode for landing the lunar module? [01:04:35] there is [01:04:55] the virtual AGC can do fully automated landings in the LM, if you let it [01:05:02] oh neat [01:05:16] if only nassp would run on this computer :/ [01:05:21] but all of the modes there (manual takeover, etc.) are supported [01:05:29] haha [01:06:05] i tried running one of the apollo 11 scenarios and it just shows a white screen and then I heard sound (XRSound) but it kept repeating and sounded like a broken record [01:06:29] I tried flying the xr2 ravenstar on this computer and got a framerate of about 1 or 2 fps [01:06:44] ouch [01:07:40] yeah [01:07:49] Maybe I can fix my other computer??? [01:08:46] But my other computer has this weird bug where, right after I reboot, I can play, say, Minetest at very cool framerates, but suddenly while playing the framerate crashes to what looks like 1 or 2 fps even though the fps meter says 4-8 fps [01:10:50] huh, that is weird [01:15:32] I gotta commute home -- will be back in an hour or so if you're still around :) [01:15:42] see ya later [01:19:18] ttyl [01:20:13] I'll still be here, but only if playing NASSP isn't a requirement for hanging out in #nassp [02:27:58] back [02:28:12] Copenhagen_Bram, not at all -- I've never really played NASSP either ;) [02:29:32] wait wot [02:29:40] who here *has* done any NASSP? [02:30:15] of people currently here, Suzuran and Thymo probably, haha [02:30:38] Guenter is our bot [02:30:40] Guenter! [02:31:20] I intend to get around to it... some day [02:31:56] Guenter: help [02:32:46] there's something wrong with guenter [02:33:06] 21:32 .commands [02:33:07] 21:32 Hang on, I'm creating a list. [02:33:09] 21:32 Sorry! Something went wrong. [02:33:39] haha [02:33:54] Thymo, what did you do to Guenter this time [02:34:01] thewonderidiot: do it right now, download NASSP, extract it into your orbiter folder, then run orbiter [02:34:05] just do it [02:34:18] if your computer can handle it [02:34:21] nope, too busy, haha [02:34:36] can't afford the time sink at the moment [02:34:47] thewonderidiot: download it now [02:34:58] i'll give you the link [02:35:04] you can work while it's downloading [02:35:16] oh nvm [02:35:18] sorry [02:35:46] let me know when you're free [02:36:00] it's going to be a few months, heh [02:36:55] hmm [02:37:05] it might not be a bad idea to download and extract nassp at least [02:37:22] just a bit of clicking and you can work while it downloads/extracts [02:37:32] I have in the past, it's on my other computer [02:37:38] oh okay [02:38:21] should I play pioneer, endless sky, hideous destructor, or cataclysm dda? [02:38:49] I only know of the last one [02:39:04] ooh [02:39:06] so that would be my choice :P [02:39:09] lol [02:39:36] pioneer is the closest thing to orbiter in the open source world [02:39:55] an elite-like space trading game with newtonian n-body physics [02:40:14] needs more developers though [02:40:36] endless sky is a space trading game with 2d semi-newtonian physics [02:41:30] but it runs on any potato that has a screen and supports opengl 3, and is more polished than pioneer and has a neat storyline [02:41:47] hideous destructor is a tactical shooter mod for gzdoom [02:42:45] guess i'll update cataclysm dda and see what's new [02:43:41] I noticed they finally bumped up to 0.d [02:43:52] yes [02:43:55] this makes me happy [02:44:18] another thing I will have to check out in a few months, lol [02:45:31] i have way too much freetime but i'm too lazy to use it for anything productive :/ [02:46:02] and for some reason i'm scared of not having that free time one day, because so many people are busy and I might become one of them [02:46:29] hehehe [02:47:21] it comes and goes in waves for me [03:03:27] what does? [03:03:41] freetime? [03:08:45] productivity more [03:08:59] technically I am on free time now, heh [03:15:14] ok [03:15:18] so [03:15:42] i downloaded nassp's readme file that was featured prominently on the sf project page [03:15:54] and I just opened it and there's nothing in it but V8.0 Alpha Release [03:16:01] y tho [03:19:22] not sure [03:19:34] although I'm not sure how much ability we have to update the sourceforge stuff anymore? [14:20:46] although I'm not sure how much ability we have to update the sourceforge stuff anymore? [14:20:52] what do you mean by this? [14:21:17] maybe it's time to switch to gitlab [14:23:34] hello! [14:24:13] NASSP is mostly on Github now, that's what he meant. Sourceforge is only getting automatic release builds. [14:26:04] Ohh okay [14:27:48] I've only read a bit of the chatlog, you are getting very low framerate in Orbiter in general? [14:30:58] yeah [14:31:15] the only good experience i've had was with the default delta glider [14:31:37] hmm, ok [14:31:43] Orbiter 2016? [14:31:53] are you using the DX9 graphics client? [14:35:34] Yeah, we used the old unix-based SF stuff that's unsupported anymore, my ability to maintain it is limited ever since their outage. I worry that if I tamper with it too much and break the wiki, I can't fix it. [14:35:47] I want to rehost the wiki but I just haven't had time. [14:36:55] I don't want to do anything provocative until I have a migration plan. [14:37:14] Everything now is on github and appveyor. [14:37:37] with some glue logic on my VPS that drives the integration. [14:38:57] hey Dan [14:39:06] hi [14:39:07] I never called you Dan, do you even want to be called that? :D [14:39:17] Doesn't matter, I've been called worse. [14:39:23] I see [14:39:30] Just don't call me "Danny". That's my (absent) father's name. [14:39:38] got it [14:39:51] unfortunately for NASSP I found a Shuttle FDO handbook and have been doing a bunch of stuff for Shuttle rendezvous [14:39:57] I saw [14:40:18] Heard you go emailed by a FDO who accused you of being a FDO. [14:40:37] Or something like that. [14:41:20] yeah, he asked if I was a former colleague with access to source code for some of the maneuver calculations they did for Shuttle rendezvous [14:41:28] I wished I had that access [14:41:42] That would be nice wouldn't it? [14:42:05] I always had this fantasy of someone leaking a tape so we could have yaAP101... [14:42:19] maybe eventually, haha [14:42:44] it helps that the AGC didn't have to guide a rocket to somewhere [14:42:44] Because then we'd have to do NASSP (Not Another Space Shuttle Project) for it. [14:43:11] not to be confused with anything else called NASSP [14:43:16] like that teacher association [14:43:56] "Ceci n'est pas une NASSP" [14:44:05] I'd be happy to get yaLVDC and yaOBC first [14:44:41] Or find tapes enough to embed Hercules for yaRTCC [14:44:47] the most effort of all of these has been put into finding LVDC code, but with no success. Shuttle software would be easy to find, yet more difficult to get [14:45:27] Yeah, I've been reading the ML traffic [14:46:06] would be fun and challenging to include any actual RTCC code in NASSP [14:46:40] we have enough documentation on I/O for various programs they had to make that work [14:48:13] working on this Shuttle stuff it's quite interesting how much they reused of Apollo at MSC/JSC [14:49:45] It's my understanding they didn't have an option, they had a bad case of fleeting budgetitis as development went on. [14:50:39] Pre-MEDS shuttle used a lot of Apollo instruments. [14:50:44] yeah. The Shuttle FDO Console Handbook from 2007 refers to memos from 1976 as the reference for some calculation methods, so they definitely kept things around for a long time :D [14:52:47] anyway, I definitely plan to properly work on NASSP again soon, still want to get NASSP 8 released for the 50th anniversary of Apollo 11 [14:53:34] Same. My big issue now is trying to get immediate issues cleared away so I can actually work. Car's in the shop, still putting out office fires, etc. [14:53:47] Amazing how much stuff can go to crap when you're away for just a half decade. [14:54:39] So your health is doing much better? [14:54:47] On top of that someone dug up more data for a project I put to bed in 2006 for inufficient data so I have a bunch of people who want that resurrected so they can carry on work with it [14:55:05] Yeah, things are right down the pipe healthwise. Still not 100% but not expected to be. [14:55:15] Health stuff is go go go. [14:55:33] awesome [14:55:40] yes, finding new documentation or data for something can seriously be distracting from what you actually should focus on :D [14:56:28] They let me go back to work middle of January, and there's a million little deferred maintenance tasks that have become one huge maintenance task that has to be cleared for move prep. [14:57:01] so basically deferred one day at a time for half a decade [14:57:28] Sort of; Some were sporadically done as they became issues, some were just ignored, there's no consistent state. [14:57:50] Some depended on work that was never done and now isn't needed so they just need flushed once no outstanding dependencies are verified [14:58:43] All in all I think I'm better off with the kidney than the unusable free time [14:59:16] yeah, for sure [14:59:50] Speaking of the anniversary do we have documentation for doing sightings yet? Star sighting is pretty well covered by horizon and landmark stuff less so. [15:01:05] you mean e.g. P23 schedules for each mission? [15:01:34] Not so much schedules as how to actually accomplish it; What am I supposed to be aiming at, etc. [15:01:59] When someone is just following the checklist MFD how do they accomplish the task [15:02:05] right [15:02:17] to be honest, we also haven't 100% figured that out [15:02:17] Because that's what I expect most people to be doing [15:02:35] and it is hindered by Orbiters spherical Earth [15:02:52] P23 expects an Earth ellipsoid [15:03:02] Wasn't that one of the things fixed in the beta? [15:03:07] nope [15:03:11] Farts. [15:03:16] I originally thought it was fixed [15:03:21] and it basically was fixed for the Moon [15:03:32] it's not really ellipsoid, but the terrain is correct [15:03:52] and the radius of the terrain all of the Moon [15:04:07] the Earth also has terrain, but it is put on top of the spherical Earth, unfortunately [15:04:23] so in that regard nothing has really changed [15:04:39] Worst comes to worst we can just omit it; our IMU doesn't drift (yet) [15:05:00] P23 is for state vector updates only [15:05:44] state vector does drift, with an imperfect propagation [15:05:55] or small mismatch between Orbiter and the real world [15:06:16] The other thing that comes up is task compression heading into burns and the like; You're trying to compress three people worth of work into one person who can only manipulate one thing at a time and takes inordinately long to move their head and hands. [15:06:19] the goal is of course to be able to navigation all on your own without SV uplinks [15:06:47] Have you seen the DCS F-14 yet? [15:07:04] yeah, that can be tricky at e.g. undocking, lots of task to do for CSM and LM at the same time [15:07:15] no I haven't [15:07:25] It's sex on a stick, you should see it. [15:07:25] Anyway [15:08:01] The F-14 is a two-place aircraft where the RIO is absolutely essential, so they wrote a system called "Jester" that serves as an AI RIO. [15:08:13] interesting [15:08:28] We're probably going to have to do something like that for NASSP, with two AI crewmembers to help you get things done. [15:08:54] with the Checklist MFD we kind of have a tool to automate the tasks of one or more astronauts [15:08:57] We already have the means for the checklist to drive switches and such [15:09:02] yeah [15:09:14] hmm [15:09:24] So it'd basically just be a bunch of small "perform task X" type checklists that the software runs on a capcom menu item or something like that [15:09:44] maybe each task should be given to a specific crewmemeber [15:09:59] and then you have a way to say: I am the CDR, LMP and CMP are automated [15:10:09] That'd be neat. [15:10:22] would basically just need one more column in the Checklist MFD files [15:10:45] and I think for the most part taks are fairly clearly split up between the 3 astronauts [15:10:51] tasks* [15:11:43] Yeah, NASA already did the hard part, we just have to transcribe it and write trigger conditions. [15:12:38] I think for NASSP 8 we won't need that. Our checklists were written so that the most important things are done [15:12:50] Yeah, there'd be no time to do this for 8. [15:12:50] like, the CSM isn't used much while the LM is on the lunar surface [15:13:40] it can go on the pile of NASSP 9 desired features then, haha [15:14:03] the next two things I'll do for NASSP will be to refly Apollo 7 and 8, just to make sure the MCC is still working properly [15:14:17] hasn't gotten many updates since NASSP 7 [15:14:39] what I find quite annoying is that our panels perform quite badly. But it's not an easy fix [15:14:43] CPU is the bottleneck [15:14:47] Any word from docmart on how far out a new Orbiter release is? [15:14:58] And yeah, I'm hoping going after 3D panels will cure that in one go. [15:15:25] That offloads a lot of busywork to the GPU [15:15:32] yeah, I'm sure it will. We basically use the second least efficient method to do panels that is possible in Orbiter [15:15:47] hmm, don't think the Doc indicated the release of a Orbiter 2016P1 soon [15:15:52] but it would be quite good for us [15:15:59] because we currently need the Beta [15:16:21] Yeah. We can just provide instructions for getting Beta though. It's hair but not too much hair. [15:16:47] most recent Beta is definitely good enough [15:17:07] one of the latest changes relevant to us is that accelerometers now work properly while landed [15:17:40] we first had a solution that added a small force for a timestep, which made the physics kick in [15:18:09] currently I have it implemented so that it just calculates the weight vector on its own in IMU, LVIMU etc. [15:18:22] if the Orbiter supplied one is a zero vector [15:18:46] haven't removed that code yet, because it would totally break NASSP 8 used with the Orbiter 2016 release [15:19:05] I thought 8 was already broken on 2016 [15:19:24] I'm not entirely sure it's completely broken [15:19:34] some people definitely had issues, which I couldn't really figure out [15:19:52] Apollo 9 can never be done on Orbiter 2016, because docked DPS burns won't work [15:20:43] bad docked moments of inertial calculation that Orbiter did [15:20:47] inertia* [15:22:40] running the Virtual AGC in NASSP has made both the Virtual AGC and Orbiter better, haha [15:24:08] Anyway, I need a reboot here, I'll be back around in a few minutes. [16:32:24] morning! [17:09:59] hey Mike [17:17:14] what's up? [17:40:57] still playing around with launch window calculations [19:08:23] https://i.imgur.com/rGTJMW0.png [19:09:01] cleaning up the monitor design a bit :) [19:40:27] almost looks like it belongs there :D [19:46:43] How did the apollo astronauts tell what vector the lunar module was traveling relative to the moon? [20:00:38] the computer knew that [20:03:06] the astronauts themselves could ask the computer in what kind of orbit they were [20:11:53] Oh? And how did the computer know that? [20:13:09] Was it possible for them to see which way the earth or the moon was moving in case the computer was wrong? [20:21:15] well, that was one of the major tasks of the computer [20:21:22] keeping an accurate state vector at all times [20:21:46] they could let the computer point the spacecraft at the Earth or Moon [20:22:11] so that would be a giveaway that something in the computer is wrong, if it wasn't pointing in the right direction then :D [20:24:12] still, that wouldn't ever really happen unless you entered P01 instead of star 01 or something :P [21:15:16] night! [13:13:42] .loggingstatus [13:13:47] .status [13:13:52] hmm [13:13:58] ah [16:52:23] morning! [17:14:55] hey Mike [17:26:18] hey [17:26:19] what's up? [17:28:40] nothing new really [17:33:15] pretty much same here. the monitor PCB has been submitted for manufacturing [17:33:46] now I'm going to try to somewhat quickly put together the opposite board for testing [17:34:45] a board that electrically looks like the AGC to the monitor board, and uses RTL stages to feed into another FPGA [17:34:55] running the FPGA AGC [17:37:41] so that you can test the whole thing before using it with the actual AGC [17:37:53] yeah, ideally [17:38:08] hopefully it will be easier to put together than the monitor board itself was [17:38:18] since I don't have to worry about mechanical constraints [17:38:33] or user friendly things or anything like that [17:48:40] yeah [17:55:58] I have a plan on returning to NASSP stuff. The launch window targeting I am working on for Shuttle should also apply to Skylab [17:56:06] so what I will try to do is launch a Skylab mission [17:56:19] implement the variable targeting in the Saturn IB LVDC code [17:56:31] and then calculate the launch time and parameters [17:56:54] nice :D [17:57:28] it will basically be a test of the targeting, SSU can't insert into a specific orbital plane yet [17:57:30] but our LVDC can [18:00:19] now the LVDC EDD for Skylab becomes really useful, because it has the required features no other EDD would have [18:01:20] like the equation to calculate the launch azimuth from desired inclination and descending node angle. No other LVDC version would have to deal with a launch window to a specific target in orbit [18:01:33] and that's one that we have? [18:01:43] that's the one EDD we have, yes [18:02:27] perfect [18:03:29] variable launch time is something that doesn't fully work yet in NASSP, so I might still have to do the targeting and then modify the launch scenario for the right launch time [18:04:24] but that's a minor inconvenience [19:52:32] mmm [19:52:46] this AGC simulation board is going to be kind of tight too [19:53:13] I wish they put 4x NPN chips into SOP packages instead of SOIC [19:54:13] they do put 2x chips into SOT23s which is nice [19:54:33] that would fit comfortably if I can figure out how to do the base resistors [20:00:21] ah, just figured out that Ron didn't actually scan every single document of E.157G back in the day [20:00:42] oh? [20:00:44] if he did, then NARA would be missing most of 1971 memos [20:00:57] so he only scanned 1968 to 1970 basically [20:01:05] aha [20:01:21] I guess that was the time frame he was searching back then [20:01:22] E.157G is 1964 to 19671 [20:01:24] 1971* [20:01:34] yeah [20:01:35] since he was trying to locate AGC software [20:01:49] and there are many boxes in that group [20:02:50] I was interested in one Skylab launch window processor one and was surprised it wasn't in the scans of first pages [20:02:54] but I guess that explains it [20:03:49] it still says it has gaps, but it is likely that it is there [20:04:00] and the numbering of the memos can be weird anyway [20:04:21] like, some memos with 70-FM-XX weren't released until way into 1971 [20:04:26] haha [20:04:36] nice numbering scheme MSC :P [20:04:58] I guess the numbers were assigned when work was started on writing them [20:06:36] ah, I guess that would make sense [20:09:23] this early Shuttle document only has an abridged version of the equations that would be in the document I am looking for [20:09:37] guess that's another one on the list [20:09:48] and this time I don't even have a box number for it [20:09:52] not even the outdated one :D [20:13:47] lol [20:15:00] if it's still chronological then it should be near the end, so not super difficult to find [20:15:21] not that I have ever requested anything from NARA directly yet, lol [20:15:48] the cost benefit analysis for that has always been a big "NO" for me [20:15:59] hehe [20:26:20] and to not think too much about those documents I don't have, I'll continue cataloging the ones I have [20:26:41] NTRS has/had especially many from 1968 and 1969 [20:27:09] is there a document that would tip the cost benefit analysis the other way if you knew they had it? [20:28:31] hmm [20:28:45] I guess I would have to know 100% that it is useful and also that it doesn't have too many pages [20:29:01] the Skylab one is definitely very good, but probably not very short [20:30:23] and most of the good ones will be long [20:31:21] yeah, that is an unfortunate correlation, haha [20:31:32] I guess the nice things about drawings is that they're super dense [20:32:15] and you are fairly sure what you are getting with it [20:32:52] that too [20:33:09] I have to put 100 MSC memos into a pot and boil it until I have 10 useful ones [20:33:16] hahaha [20:51:35] night! [16:52:19] morning! [16:59:21] good morning! [16:59:37] hey [16:59:51] what's up? [17:01:22] well I just joined, so I have nothing new. yet. haha [17:03:39] haha [17:04:16] just trying to understand one of the Shuttle Launch Window Processor routines right now [17:04:57] it's not a complete program flow, sometimes it just says "Calculate IIGM" [17:05:06] without an equation for it [17:05:11] boo [17:06:13] and there are all these extra features with their control flags, which I am currently not interested in [17:06:28] makes it a bit difficult to overview the whole thing [17:06:44] definitely useful for Skylab [17:06:50] not really for Shuttle [17:07:33] Skylab 2 was originally supposed to launch 1 day after the Skylab itself, but it was postponed due to launch damage [17:07:44] and the retargeted launch had a different insertion orbit [17:07:54] for that these extra features are useful [17:12:27] are they things that can be added later relatively easy though? [17:13:17] only if I stick to the logic flow as it is [17:13:27] and just leave parts out [17:13:40] sticking to the logic flow is difficult, it's presented in a very confusing way [17:14:07] like, when there is an "if then else" it points one arrow to the "then", one to the "else" and another one to the continuation [17:14:17] nothing from the then/else back to the main flow [17:14:51] so you basically need to figure out yourself where it should continue with the main flow after the if [17:22:26] bleh [17:23:39] as you were asking, there is an inner iteration loop that I would probably not need right, but I'll probably implement it any way to not hinder any future additions [17:23:52] need right now* [19:33:47] grrr [19:33:52] modern electronics are frustrating [19:34:07] at least, when trying to interface with very old electronics nicely [19:38:18] Hey Mike, what's up? It's only a 50 year technology gap! :) [19:42:18] it's really the modern electronics which are the problem, the old ones are simpler and easy to handle, right? :D [19:44:07] haha yeah [19:44:18] I was just breadboarding stuff for the monitor last night [19:44:28] and I'm worried about edge rates [19:45:07] with the FPGA set up for LVCMOS33, the input threshold for a logical 1 is 2.00V [19:45:32] which is quite a bit higher than the threshold for the RTL gates, which is only 0.8V-ish [19:46:22] and initial testing made it look like a 3.3k pullup to 3.3V might not be strong enough to handle the 1MHz signals [19:47:31] it does make it to the needed 2V, but with a 50% duty cycle 1MHz wave like MONWT, it only hits 2V something like 75% of the way through the high pulse [19:47:42] not a whole lot of margin there [19:53:03] Yuck [19:53:38] as far as I can tell there's no safe way for me to reduce the input threshold in the FPGA without damaging it [19:53:58] Simplest path forward would be to stiffen the pull ups per our discussion a couple weeks ago if the RTL gates can safely sink the current [19:54:03] yeah [19:54:08] they definitely can. [19:54:34] I went digging through the schematics for the buffer box last night after seeing that on the scope, to see what they used [19:54:42] they also used 3.3k pullups... but to 10V instead of 3.3V [19:54:55] That would also work....... :/ [19:54:57] so I could reasonably drop my pullups to 1k [19:55:12] Agree. [19:56:17] 10V wouldn't work for me without adding a transistor input buffer, that would destroy the FPGA pins haha [19:56:49] Yeah, my sarcasm flag was not set on that last reply... [19:56:56] hahahaha nah I got it [19:57:18] worst case I could make a board that replicates all of the circuitry in the buffer box [19:57:31] but I still feel like it is probably possible to get this to work with direct FPGA pins and pullups [19:57:51] True, but hopefully not necessary. Re-try your analysis with the 1k value. [19:58:07] yeah, I'll be trying that first thing tonight [19:58:33] I wish I had numbers for how much capacitance to expect from the AGC side [19:59:16] and it's a good thing I put 500mA regulators on this thing even though I was only expecting to use 100mA [19:59:31] since I may need all of that current [19:59:48] Any documentation with scope traces? Could you infer an approximate capacitive load from an old photo of a scope trace of a signal? [20:01:08] Actually, shouldn't it be the capacitive load of the RTL gate's output? Should be a spec for the gate??? [20:09:42] hmmm [21:33:45] ah [21:33:46] haha [21:33:48] classic [21:33:58] hmm? [21:34:10] some of the calculations I was looking for were of course hidden in the AS-200 IBM RTCC documents [21:34:17] oh perfect :D [21:34:19] every time [21:34:34] sometimes not easy to interpret or badly handwritten [21:34:46] but always in some form there :D [21:35:54] I love documents like that [21:35:57] that just keep giving :D [21:43:08] definitely a more primitive form of what they had for Skylab and Shuttle, but it has equations where the other document is just hinting at how it should be done [21:44:04] and nothing on the whole "differential nodal regression" thing [21:45:26] anyway, good to hear that news from Ron. [21:45:28] Good night! [00:00:39] hey SteveH [00:01:09] answering your question from earlier... capacitance doesn't seem to be specified in any of the NOR chip drawings [00:01:16] and wouldn't the backplane also be a big-ish contributor? [00:09:16] Yes backplane would be a contributor. Most likely too risky to hang a capacitance meter on one of the monitor pins of the AGC. [00:10:51] scope trace photos is an interesting idea, if we can find one good enough [00:11:49] there's a bunch in the improvement study, and I think maybe one or two in the design review [00:13:02] Could most likely assume maybe 5-10 pf worst case. Wire should only be 2-5 pf for 1-2 foot length. Add a little more for connector pins etc. Just a rough order of magnitude guess [00:36:13] yeah that sounds reasonable [00:44:21] I should be working on gyro emulation this weekend. Had to order 40 pin version of PIC since gyro requires more IO signals than I could get on a 28 pin version. Think I've figured out the interfaces. [13:29:57] hey [14:03:40] hey Niklas [14:05:21] what's up? [14:09:57] Ive been learning the F-14B with DCS World recently, managed to fly a few missions with it cold & dark to shutdown. As complex as they made it it actually is not too bad to learn as its a very analog airplane to begin with. No FBW, primitive HUD and INS. The INS btw has been very well done, its quite dated technology and prone to lose accuracy with high-g maneuvers which is modeled in the sim. [14:10:24] nice [14:11:13] I'm looking at Shuttle launch window calculations [14:11:19] the pilot station is quite simple to learn, and I have been using Jester, the simulated RIO to operate the back seat. The RIO position itself is what will be chellenging to learn [14:11:27] challenging* [14:11:29] ah right [14:11:43] who was talking about that [14:11:50] ah right, Suzuran [14:12:18] he was also flying the F-14 a bunch [14:12:57] Shuttle launch window targeting is directly derived from Gemini/Apollo/Skylab calculations [14:13:04] Its very impressive [14:13:16] Oh cool [14:13:19] SSU can currently not insert the Shuttle into a specific orbital plane, only inclination [14:13:31] so what I am going to do is implement this for the RTCC MFD as well [14:13:41] and test Skylab launch and rendezvous with it [14:14:00] for the Saturn IB LVDC only [14:14:17] so it would calculate launch azimuth, inclination and descending node angle for the targeting [14:15:02] and should make it possible to fly the rendezvous profile with the Skylark routines in the RTCC MFD [14:15:28] with minimized plane change requirements [14:15:47] should be quite fun to see the LVDC deal with actual yaw steering [14:16:19] the mission to the Moon had variable inclination, but the orbit was still in-plane, so over the launch site [14:16:25] missions* [14:16:43] right makes sense [14:17:06] Any word on if Skylark listing might be hiding somewhereÉ [14:17:11] nope [14:17:36] There is a "Prelaunch Targeting Display" for the RTCC in one of the MSC memos, I'll probably use that [14:22:28] when running a Skylab mission you would have to use the RTCC MFD for NC1, NC2 and NCC [14:22:44] probably NSR as well [14:23:10] but after that you could use the CMC [14:23:39] right [14:24:03] not Artemis though [14:24:15] Lambert aimpoint is broken in Earth orbit [14:24:19] so P34 and P35 mostly [14:24:53] hmm [14:24:58] that's weird though [14:25:05] P37 uses lambert aimpoint guidance as well [14:25:14] surely that isn't broken in Earth orbit [14:25:23] must be a P34/P35 specific issue [14:27:33] so, I hope I can come up with something useful for both NASSP and SSU for launch window and targeting [14:28:25] too bad we can't move the liftoff time yet in NASSP without scenario editing [14:28:53] yeah, Ill have to run an SSU mission sometime [14:29:22] but I also have to finish making those Apollo 10 & 11 Scenarios lol [14:30:23] Has there been any ideas or insights recently on ways to improve the LM ECS stability? [14:30:29] not really [14:30:39] I tried awhile ago and didn't have much success [14:30:51] next thing I will do in NASSP is fly Apollo 7 and 8 again, create new scenarios and fix MCC issues [14:32:05] I think I made one single tank more stable [14:32:13] descent O2 manifold or so :D [17:17:08] morning! [17:17:30] Good morning Mike, any progress last night? [17:18:12] yeah, I put together a test that pretty much resolved my fears [17:18:21] https://i.imgur.com/5hnf2Fl.png [17:18:42] (the diode is there to speed up the saturation recovery time of the 2N3904 since I don't have any 2N2369s in stock yet) [17:19:17] Great [17:19:41] yellow is the open-drain output from the FPGA, cyan is getting a 3.3k pullup to 3.3V as will be seen on the monitor, and pink is just a passthrough on the FPGA that shows what it thinks the logic level is [17:20:18] most of the delay on the falling edge is still from the 2N3904 recovery, and I can definitely live with this as it is even without that delay removed [17:22:56] and it sounds like our replica Malco pins will be ready mid-April [17:23:52] Still shooting for the July date then? [17:24:32] yep, doing everything we can to meet it [17:25:20] how's CDU stuff going? I saw your message last night after you left [17:27:05] I should have the hardware together to write up some code to emulator the gyros this weekend. Think I understand what's happening during power up of the IMU, coarse align, and fine align. [17:27:16] emulate* [17:28:05] There's about 21 or so signals involved in the dynamic running of the gyros plus another half dozen mode control and status lines. [17:29:11] awesome :D [17:31:45] gyros power up in a state similar to the cage state with physical angles set to zero degrees by IMU hardware. AGC also assumes zero degree power up. Coarse align injects pulse width defined angles into the CDU error counters to physically move the gyros to desired angles for coarse align. fine align uses discrete pulses to torgue the gyros for fine align. Gryos report back relative changes in angle to the AGC via discrete up/down p [17:33:25] The gyro angle, coarse align, and fine align are each groups of 6 signals per. For a total of 18 signals. Then theres the CDU clock used for clocking pulses into and out of CDU, and a set/reset signal used during fine align [17:34:05] Doing this from memory so forgive the paraphrasing [17:34:47] the CDU can generate pulses at different rates depending on mode right? [17:35:03] I feel like I remember reading somewhere that at some times it's capped to 3.2kpps, and others it's 6.4kpps [17:36:51] Yeah, that's one I need to experiment with. There's only 1 CDU clock signal but the cause align is at the lower rate. Not sure if coarse align resolution is defined as 2 CDU clocks per increment or something like that. It will take some experimentation to feed a desired angle into the emulator from my GUI and see if the readout on DSKY agrees. :) [17:37:14] coarse align* (cannot type today) [17:37:21] haha [17:37:40] well potential good news then [17:37:57] Ron was approved as a NARA volunteer and is doing his first day at the archives today with access to the high-rate scanning machine [17:38:03] I know enough to be dangerous, the rest will sort itself out. [17:38:16] and if it goes as quickly as he hopes, he'll make it up through 2007xxx drawings, which I believe to be mostly CDU [17:38:19] That's awesome! [17:39:39] I've been finding that the ability to drive the emulators I'm creating (like PIPA) and being able to see the values on the DSKY as well as the downlink allows me to converge on the correct solution quite well. The AGC is always right so I just keep at it until it makes sense and the numbers agree. [17:54:26] :D [17:54:44] yeah that's really nice to have a source of "truth" that knows how the thing is supposed to work haha [18:37:08] hey guys [18:38:08] hey [19:32:08] SteveH, if you are becoming a CDU expert then you could do a proper implementation of them for NASSP, haha [19:32:17] also, there are different types of the, right? [19:32:34] I remember having trouble using our implementation of the RR CDUs for the OCDUs in the CSM [19:32:53] because there is some error counter to read counter connection of sorts [19:33:37] hopefully we will learn much more about the differences between the CM and LM CDUs in the coming days :D [19:33:56] we do have one data point for this, let me look something up [19:34:07] surely learning too much for NASSP purposes, haha [19:34:27] Delco manuals have a nice visualization of it [19:34:31] well, not necessarily [19:34:51] we needed this level of understanding of the AGC in order to get it to work in NASSP for the landing [19:34:59] the higher-level documentation never would have gotten us there [19:35:44] https://ia800609.us.archive.org/BookReader/BookReaderImages.php?zip=/1/items/acelectroniclmma00acel/acelectroniclmma00acel_jp2.zip&file=acelectroniclmma00acel_jp2/acelectroniclmma00acel_0195.jp2&scale=1.4188102893890675&rotate=90 [19:35:50] there's the LM CDU compatibility sheet [19:37:47] so many numbers that don't mean anything to me :D [19:38:07] I think how it works in the OCDUs is an additional connection from read counter to error counter [19:38:28] so if a specific bit of the read counter changes, then the error counter is incremented or decremented [19:38:29] hold on [19:39:09] similar to how the CDUs cause that for the counter in the AGC [19:39:29] just, two bits further to the left, haha [19:39:41] https://i.imgur.com/M8XFujY.jpg [19:39:50] there's the compatibility chart for the CM CDU [19:40:30] part of it [19:40:41] hm? [19:41:07] oh [19:41:08] the picture is cut off at the bottom [19:41:09] eh, enough of it [19:41:16] the part numbers are the interesting thing [19:41:24] if you say so, lol [19:41:37] the software definitely expects that behavior [19:41:44] it looks like the part numbers are the same, but there's no dash number overlap [19:41:57] so yeah, there is a physical difference, but it's probably somewhat minor [19:41:58] I've tried it, sextant drive is unstable [19:43:19] I'm really excited for CDU schematics haha [19:43:34] for now, just look at the LM-8 Systems Handbook [19:43:44] I want to put the NOR logic portion into an FPGA :D [19:43:47] RR commands through the CDUs are somewhat adjusted for a delay in the RR reaction time [19:44:02] but the optics drive works differently, software side [19:44:26] it really needs that error counter being automatically changed by the read counter [19:44:29] or else it won't work [19:44:40] yeah [19:44:43] and because that is done when a specific bit is flipped in the read counter [19:44:45] I'm curious to see how different they'll be [19:44:50] I couldn'T really figure it out [19:45:27] probably needs some better mechanism for an overflow etc., not so easy to do [19:46:09] I forgot if there was anything special about the ICDUs [19:46:22] I think there is a difference as well, or else I would have implemented those already [19:46:40] so our special CDU class is currently only used for the RR CDUs [19:46:55] because that's the only one that really needed needed it [19:48:09] the others can be done by some cheaty ways [19:49:42] hmm [19:49:50] I was just going to ask if there was a difference for the ICDUs, heh [19:50:21] hmm [19:50:28] the IMU code is doing some parts of it [19:50:47] and the error counters for the FDAI are saved somewhere randomly [19:51:18] ah yes [19:51:22] still in the GDC [19:51:32] it looks like the LM CDU has five "coarse system" modules in it, while the CM CDU only has three [19:51:35] no idea who had the idea to put them there :D [19:51:48] haha [19:52:10] yeah, the optics are never really coarsed aligned I guess [19:52:35] if that is meant with that [19:52:41] there is a zero switch instead [19:54:26] there's no different part numbers between the actual modules in the LM and CM CDUs [19:54:44] there are differences in the dash numbers, but that could well just be the ~6 year difference between these two documents [19:54:59] so the differences might just be backplane wiring [19:55:04] and the lack of those two modules [19:55:54] Don rudely lost the corresponding pages from his copy that would have the answer to that :P [19:57:09] also scrolling through this document [19:57:19] there's a lot of interesting things we'll be getting drawings of if Ron makes it to 2007xxx [19:57:51] and there is functionality for NASSP to gain with a better OCDU implementation [19:57:55] almost forgot about that [19:57:59] P24 in Artemis [19:58:11] it drives optics while the CMC mode switch is in manual, not CMC [19:58:29] that doesn't work right now with our implementation [19:58:37] and it's not an easy fix [19:58:51] optics mode* [20:02:21] yeah we need to do the big pulse conversion at some point and make a real CDU sim :D [20:13:52] Was away for a while, would be happy to look into the CDU stuff once I actually get it working on my hardware platform. [20:15:08] Yes, each CDU appears to be slightly different in terms of resolution of the error values, etc. Discrete signalling also appears to be different. Looks like a case of common hardware subcontracted out to 3 different vendors for radar, optics, IMU... [20:25:23] you mean within the CDU? I'm pretty sure the CDU itself is all MIT design [20:25:35] what they're interfacing to is definitely all different vendors though [20:25:49] plus the electronic CDU has a weird direct heritage to the mechanical Block I CDU, and all of its circuits are direct translations of the mechanical gear ratios etc. [20:25:57] it would probably look different if it was designed electrically from the start [20:32:06] so Block I CDU is the Steampunk version of Block II CDU [20:32:15] haha yes [20:36:04] I think what Steve meant is that 3 different subcontractors for RR, optics and IMU wanted three different things from the CDU [20:36:12] right [20:36:31] optics and IMU at least were designed at MIT itself, right? [20:47:11] I'm not sure to what extent Kollsman and AC took designs from MIT and built them, or designed them themselves [20:47:29] I thiiiink they were? [20:51:49] I can't imagine Doc Draper letting someone else tell his lab how to build an IMU [20:54:04] hahahaha fair enough :D [20:54:23] I guess it's more the optics that I'm not positive about [21:03:06] night! [16:46:01] morning! [17:16:53] good morning [17:17:33] good morning! [17:18:54] hey [17:35:55] hi Niklas i'm gonna start a new apollo 11 mission and im just wondering if there have been any major changes? [17:36:28] don't think so [17:36:38] the last big thing I was working on was the SCS [17:36:53] so if you are doing a GDC align, keep that button pressed for a bit [17:37:00] it's not instantenous anymore [17:37:07] not sure if you already knew that [17:59:05] yes [18:36:33] thewonderidiot, ever seen this? https://web.archive.org/web/20100518051255/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19780070361_1978070361.pdf [18:36:54] yep [18:37:22] it's in our document library [18:37:23] why? [18:38:04] oh, I was just searching through the NTRS list again, just found that randomly and hadn't saved it myself [18:38:18] gotcha [18:38:19] forgot to check if it was on the Virtual AGC website [18:38:34] I just assumed not, because I didn't have it saved myself :D [18:38:37] hehehe [19:02:09] it's not like we are going to run out of things to get from NARA [19:05:22] yeah [19:06:14] not even for any AGC related stuff any time soon [19:06:24] most of what I am interested in is only partially related [19:09:09] would be great to have someone who is directly helping with NASSP living near Fort Worth... [19:10:06] then it would be scanning all day and all night until I have a complete of Mission Planning and Analysis Division memos :D [19:10:43] complete set* [19:17:42] haha [19:17:51] yeah that would be great [19:17:53] still have no good overview how many I already have. From 1967 to 1969 I have a loot [19:18:08] but at that time there were like 300 per year [19:18:16] still cataloging [19:18:53] you should organize your collection and get it online at some point [19:19:15] most of it comes from the archived NTRS [19:19:25] UHCL doesn't usually have these MSC wide memos [19:19:41] they have more branch or department internal ones [19:20:06] some are still on NTRS [19:20:23] so if I put it online I am really just putting the documents up again that NTRS took down [19:20:28] doesn't sound like such a good idea [19:20:55] Ron and I do it all the time :P [19:21:31] true [19:23:19] at least I could make a list with all of them, with links to the current and archived NTRS [19:24:13] so basically some NASA archivists job [19:25:01] or put it on a private google drive or something and only share it with a few people [19:27:14] wanted to randomly start with 68-FM-1, Apollo 5 consumables analysis. Somehow that one isn't available [19:27:24] it's in the restricted NTRS list and all, but not online [19:27:37] very random, it's online for almost all the missions [19:27:44] so, good start :D [19:28:05] if there's one thing we've learned about the restricted NTRS, it's that the distinction between restricted and unrestricted is ridiculous and arbitrary [19:28:08] and inconsistent [19:28:09] :P [19:28:43] yep [19:29:04] and what got uploaded to the public one pre 2013 is also fairly random [19:30:50] probably some leftover memos that never got shipped to NARA [19:51:07] oh yes! [19:51:30] speaking of NARA, I just got the scans for those three buffer box-related documents [19:51:37] and this one has lots of details [19:52:25] oh, nice [19:52:40] looks like I was pretty much right [19:53:53] "Teh G&N buffer shall form a part of the Digital Test Command System (DTCS) which is the uplink portion of the Automatic Checkout Equipment (ACE)." [19:54:28] "The G&N buffer shall receive remotely generated digital test commands from the control room via the DTCS and shall store, verify, and shift out G&N data in appropriate format to the G&N on-board computer." [19:55:16] so uplink [20:05:36] more drawings to get though [20:05:43] MC 901-0675 for the DTCS [20:06:11] the classic rabbit hole of drawings [20:06:21] actually, I think it's just that one that I need [20:06:39] and that would be a DTCS drawing? [20:07:04] yeah, but it specifies the electrical design of the buffer unit, and the interface between the buffer unit and the AGC [20:07:10] (which is the part I already know, but still) [20:07:25] I see [20:07:44] I wonder if all the padloads went through this buffer... [20:08:18] possibly [20:08:40] bit positions 1 and 2 are the mode select, so that explains why it's 18 bits [20:09:20] strangely they use it like a single bit [20:09:47] 10 means "load buffer memory" and 01 means "check buffer memory and execute" [20:09:57] 00 and 11 are apparently not allowed [20:12:12] interesting [20:14:22] the number of times that one document is referenced makes me fear for its size [20:19:13] the DTCS one? [20:19:29] I imagine it being a bit more complicated than a simple buffer [20:25:11] it appears to cover the whole system, including the buffer [20:25:31] like this document doesn't have any details on timings or voltages for the buffer unit because they're all contained in the DTCS one [20:28:07] can you hear that sound? It's dollar bills falling out of your pocket [20:28:55] at this rate I'm going to spend more on documents about this thing than it will go for at the auction :P [20:29:15] reverse engineering isn't so easy though, haha [20:33:23] yeah, already this block diagram of how stuff moves around inside the box is super helpful [20:33:34] it's not entirely clear what it's talking about with "coincidences" [20:33:50] I think you might need to write the same data twice, once with each mode? [20:34:04] and it checks to make sure that the data is the same both times before shifting it out maybe [20:34:18] yeah, could be [20:44:33] does "coincidence" get mentioned multiple times? Only found one so far [20:46:09] I think so [20:47:20] hmm [20:47:35] 3.3.3 - "coincidence check" [20:47:58] 3.3.4 - "In the execute mode, coincidence shall start the clock..." [20:48:20] 3.3.6 - buffer register reset if coincidence is not achieved [20:50:07] 3.3.4 seems to be explaining it, for the most part [20:50:39] "contents of the G&N buffer" versus "DTCS staticising register in the comparison gates" [20:53:08] what is the DTCS staticising register? [20:53:11] haha [20:54:26] probably something outside of the buffer [20:57:38] yeah, that's what I was thinking [20:57:44] but the only way in is through those same lines [20:57:54] which is what makes me think you just give it the same thing twice, with different modes [21:00:13] hmm [21:00:23] could be [21:00:30] good luck figuring it out. Good night! [21:20:02] hey SteveH [21:39:01] Hey [21:42:48] what's up? [22:16:27] I got scans in for those drawings related to the computer buffer unit, and one of them is really good [22:20:25] That's going to take a little while to read through. Have you had a chance to study it yet? [22:23:26] a little bit [22:23:45] the extra two bits control the "mode", which can be either Load Buffer Memory or Execute [22:24:01] and there's some comparison/consistency checking that I don't fully understand yet [22:24:22] it was part of the Digital Test Command System [22:26:29] I'll take a look in detail a little later. I'm puzzled by the serial output nature of the box(including the shift register) and how that sort of signal could apply to the G&N system [22:26:45] it's uplink to the AGC [22:27:01] parallel command in, 1 and 0 pulses out to the AGC directly [22:27:29] Okay. so the mode must be related to loading a word and then "executing"it by serializing it out to the uplink? [22:27:37] yeah [22:27:45] gotcha [22:27:57] I thiiiiiink that the 16 bits of command must be the same for both the load and the execute [22:28:02] but that isn't perfectly clear [22:28:24] there is one more drawing that this references heavily, MC 901-0675, which covers the whole DTCS [22:28:30] and has the electrical specifications for this box [22:28:45] although the number of times it's referenced makes me fear for its size (and scanning cost) [22:28:50] I'm going to ask them about it at least [22:28:59] Would make sense. That interface is triple-redundant within each 16 bit word. Forcing the load and execute words to be the same would just add another layer of safety [22:30:59] Sounds like you could be opening up another whole project if you keep going. :P [22:31:06] hahaha [22:31:34] well the hope is that it's easy to figure out and restore, so we could use it as the uplink driver in July [22:31:36] but we'll see [22:32:13] Oh okay, I was missing the whole reason for this. You have one of these boxes in-hand??? [22:32:45] well, not yet [22:32:48] https://www.rrauction.com/preview_itemdetail.cfm?IN=5094 [22:32:56] there's two going up for auction soon [22:34:20] Okay, this all makes much more sense now. I was questioning your sanity for taking on another project. Didn't understand the reason behind the whole effort. :) [22:35:18] I can give you a 28-pin DIP package with uplink/downlink running between 3.3 and 5V. uses a SPI interface. embedded code still a little buggy... :D [22:38:29] hahaha [22:38:43] I might take you up on that if this doesn't pan out :D [22:40:08] Just let me know. Guess I should try to fix this nagging issue where every once in a while the PIC locks up and I need to perform a HW reset. Appears to be a race condition between one of my state machines and one of the timers. [22:41:26] Chip runs from 2.3 to 5.5 volts [22:58:24] that's a pretty wide range, nice [16:42:42] morning!