[16:15:07] NASSP Logging has been started by n7275 [16:15:09] hello [17:02:54] n7275, long talked about little project, adding support for your IMU biases in the padload generator. For best compatibility, what sort of units are you using for the mission file? [17:03:48] oh IMU drift is a matrix? [17:06:09] ah I see it in your PR [17:06:17] the same units I wanted to use :D [17:06:27] cm/sec^2 etc. [17:29:24] morning! [17:38:58] hey Mike [17:45:39] Skylark is coming along nicely -- still getting nice big chunks slotted into place. down to 16.5k differences, and I should be able to get ebank 5 all sorted out tonight. ebank 7 is also looking slightly less scary now that I've gone through and deleted all of the erasables for programs that no longer exist [17:46:13] yeah ebank 7 would be very scary, but it's probably a bit emptier than Artemis, right? [17:47:30] a bit emptier, yeah. but there's still a decent bit of overlaying going on https://i.imgur.com/Lkt81Hy.png [17:47:54] ah yeah, layer 7 thanks to P50 :D [18:50:40] thanks Sunburst for the nice table of IMU bias conversion factors [19:22:54] got the Apollo 11 IMU compensations identical to the actual padload. Not that easy with all those weird scaling factors [19:23:09] CMC, now LGC :D [19:37:18] there is a factor 2x in the LGC padload that I can't explain, but otherwise I have it [19:59:30] nice :D [20:15:01] hi, I'm back [20:26:09] welcome back [20:26:43] ok I am off by 1 bit in NBDX in the Apollo 17 CMC padload. I think that means I am using the wrong MERU conversion factor [20:30:07] n7275, where did you get your definition of it? [20:36:06] great, if I use a different definition something else is off by 1 bit... [21:15:33] I hadn't actually converted any for my spreadsheet [21:17:14] I was just using the padload value, and either the "flight load" value from the mission reports, or an average of NBD for the mission [21:17:38] ...I probably should've noted that somewhere [21:19:21] I do recall when I was doing my initial testing that a precision of 0.1 MERU listed in the padload is not sufficient to exactly match the AGC compensation [21:19:52] ah that's interesting [21:20:14] in a way it's a typical padload issues where something doesn't match exactly. Will need a bit more looking into. [21:20:46] the Earth rotational rate changes over time, I hope they didn't adjust MERU for that :D [21:21:32] I think the definition is 15°/hr [21:22:04] and what can also be confusing in the padload documents, the AGC value it gives usually matches exactly the octal. That means the engineering value is converted to octal, with a loss of precision, and the "AGC unit" it gives is converted back from octal. [21:22:25] so you can't derive conversion factors between engineer and AGC values [21:23:18] 15° per hour would be a very rough conversion of the Earth rotational rate, but I can try if that gives more consistent results [21:23:30] well [21:23:56] it matches exactly the rate compared to the Sun of course [21:24:06] but not the inertial rotational rate of Earth [21:28:52] yeah I got myself very confused on sidereal vs synodic roration rate when I started looking into this [21:29:28] I know there is a document somewhere that actually defines exactly what the unit is [21:30:59] and in the end there always is the possibility of a sloppy octal conversion [21:31:44] there is some padload, I forgot which one, which keeps the exact same value and scaling but is 1 bit different between a few missions. Sometimes it's this value, sometimes the other [21:32:07] same engineering value* [21:32:13] https://books.google.com/books?id=009p-dfd-kgC&pg=PA14#v=onepage&q&f=false [21:34:28] 7.27e-8 still seems not very exact, but might be what they used [21:34:31] https://www.ibiblio.org/apollo/listings/Sunburst120/IMU_COMPENSATION_PACKAGE.agc.html [21:34:39] this has a "conversion table" [21:34:43] also very interesting [21:44:23] oh [21:44:43] the "ERU" value in Sunburst is the inertial Earth rotational rate [21:45:04] but that "MERU" value in gyro pulses per centisecond actually seems to use 15°/hr exactly [21:49:54] still one bit off. Maybe I have to accept that they didn't convert this properly :D [21:52:32] I'll check on all the flown padloads over the next few days. The conversions are implemented in the padload generator, just have to be made available via the GUI. [21:52:41] night! [23:08:37] .tell indy91 maybe this is another IEEE-754 versus IBM 32 (and 36) bit and Honeywell 48bit floating point implimentations