[15:13:29] NASSP Logging has been started by indy91 [15:13:31] hey [15:16:44] hey Niklas [15:19:48] seems like Mike it lauching to orbit :D [15:21:04] is* [15:30:42] morning! [15:31:19] hey [15:31:22] good job :D [15:31:25] one simple bug eh [15:31:48] thanks :D [15:32:28] yeah one very subtle bug that I found quickly by getting lucky haha [15:34:13] I plotted X, Y, and Z components of inertial velocity during a launch and one of the lateral components (Y I think?) started increasing so much after a bit that I became convinced it wasn't that the attitude was just 0,0,0 [15:34:35] so I spent some time looking at the IGM, and realized quickly it is very big and very complicated [15:35:20] looked at some equations in the EDD for it, and noticed this MS4 matrix used at the beginning of the calculations. so I set a breakpoint to see if the routine to construct it was being hit [15:35:39] the breakpoint triggered, but instead of continuing I decided to single step through it for a bit [15:35:54] and noticed that it was loading a multiply product before yaLVDC had it ready :D [15:37:12] I was also slowly getting to the matrices haha [15:37:28] the last thing I looked at yesterday was the conversion of the simulated acceleration from body to inertial coordinates [15:37:35] MBS matrix [15:39:06] that one was probably broken too if they built it the same way [15:46:56] so what's the next step. LVDA work for the non-repeatable sim? :D [15:49:00] I think LVDA work for telemetry. I want to get this running in an FPGA [15:49:34] and then yeah, moving on to stuff I need for non-repeatable [16:01:57] I like LVDA schematic pages like this one :D https://i.imgur.com/1KXjJHB.png [16:20:38] is it the "not used" part? :D [16:21:19] hahaha yeah. very easy to implement this page because I can ignore 5/6ths of it [16:58:02] I hate RTCC optical support displays... [16:58:44] they seem so annoying to use [16:59:22] this LM optics display has several different modes, but you don't actively choose the mode anywhere, it gets chose automatically based on what values you ommit from the G20 MED [16:59:49] and all the data you input manually for the display aren't shown directly anywhere. Not until you recalculate the whole display [17:00:38] I want to avoid users of the MFD having to do the MED input. But internally I want it to work like a MED input. There is really no good way to make that happen in this case. [17:00:57] I will just come up with my own input methods, with the same exact display format though. [17:01:12] first step, add a button where you choose the display mode :D [17:01:34] then any data input you do afterwards is routed to the right place and shown immediately [17:01:57] oh wow yeah that is weird [17:03:56] they needed a person trained in understanding just these G-type MEDs :D [17:10:16] yeah I think the display is a lot nicer to use if I just give it a button to choose the mode [17:11:26] and there are acronyms in the MED that are not explained anywhere, also not helping... [17:13:19] attitude codes "MM, OP, LV, PP, DD" [17:13:32] I am somewhat sure that MM is manually entered attitude and LV is live telemetry [17:13:35] the others... [17:14:12] we can't use anything but manually entered angles yet anyway, so probably not so important [20:07:06] night! [15:24:08] morning! [15:28:55] hey Mike [15:29:36] what's up? [15:33:38] continuing a bit of work on this LM optics support display. And you? Doing some more repatable sims just because you can? :D [15:36:36] haha I have had a few running in the background [15:36:59] I tried one where I removed the T+145s repeatable simulation termination but it crashed on something else [15:37:09] which I guess isn't too surprising and I haven't debugged yet [15:37:14] but mostly I've been implementing more LVDA [15:41:23] lots of modules needed for telemetry to work... [17:03:50] hey guys [17:04:05] thoughts on this: https://github.com/orbiternassp/NASSP/discussions/1044 [17:21:57] hey Matt. Hmm, no idea really. I think our FDAI would fall under the same license as anything else. I'll just ask Dan [18:21:01] good evening [20:07:39] good afternoon! [20:08:03] the LGC is being rude and tries to talk to the RR when you already switched to slew [20:08:08] I think that is causing the 1210 [20:08:25] again a case of the radar activity bit not being reset [20:08:31] or the interrupt not happening or so [20:10:58] because we have to do that in NASSP code with the current Virtual AGC [20:11:18] and the LGC signals are only being processed with the RR switch in LGC [20:11:54] I know, with a certain Virtual AGC PR it all wouldn't be a problem :D [20:12:00] hahahaha [20:12:28] maybe this problem would go away, but it would cause us so many more :D [20:12:31] I might just add a piece of code in our interface class to the Virtual AGC that processes this [20:12:42] instead of letting the RR/LR/VHF ranging do it [20:13:20] because there it depends on powered/unpowered, certain switch settings etc. [20:13:59] right. which stops the LGC from getting RADARUPTs when it should [20:14:15] it's the radarupts that's probably causing it, right? [20:14:26] we are also resetting the radar activity output bit [20:14:33] might be the lesser issue? [20:14:40] but it can do both of course, as our current code [20:14:42] I have not been following the conversation in discord at all, so I'm only tangentially aware of what you're talking about lol [20:14:57] but missing radarupts could certainly cause issues [20:16:30] in the Apollo 11 procedures they are running V63, to compare RR range and range rate to the tapemeter [20:16:43] V63 updates those once per second by asking the data from the RR [20:17:06] but then when you switch to RR mode slew, our code doesn't process radarupts anymore [20:17:13] which I thought wouldn't be a problem [20:17:25] because the LGC wouldn't really try to talk to the RR then anyway [20:17:32] but apparently it does [20:17:39] maybe it's just slow to react [20:17:53] might get garbage data one time and then stops trying or so [20:18:19] normally you quit V63 with V34 [20:18:30] but in this one case they go to slew before doing so [20:18:47] aha, I see [20:20:08] we can't really remember getting 1210s from this though [20:20:24] Ryan more than me, I was more like "I can't even remember going to slew within V63!" [20:21:36] hmm already coming up with some potential issues [20:21:58] RR data can have different scaling [20:22:05] the input bit for that is set in the RR timestep [20:22:29] so if I move the radarupt away from there [20:22:36] then there could be a desync [20:22:44] hmm [20:22:54] maybe not if the RR already generated the right data [21:04:04] night! [14:13:29] hello [15:15:09] morning! [15:16:06] hey [15:16:31] I have a solution for the 1210 alarms I think [15:17:23] oh? [15:17:25] added a function in the ApolloGuidance class, our interface to the Virtual AGC [15:17:40] I moved the code that does the interrupt out of the RR and LR class [15:18:06] so that processing it doesn't depend on RR/LR switch settings, and powered/unpowered [15:18:23] so the RR and LR do their normal timesteps [15:18:33] then it calls that new function, where it checks the radar activity bit [15:18:39] and if it's there, get the data from the RR/LR [15:18:44] and cause the interrupt [15:18:47] and reset the bit [15:19:29] so basically not really any new code, it's just done in one central place [15:19:54] before in the LR and RR timesteps [15:20:04] nice :D [15:20:24] and it had special code when they are unpowered and any radar requests are coming in, also an ugly solution that is now gone [15:20:53] just have to test it. Actually, there is one new case where the AGC wants data but nothing is provided [15:21:13] not sure what would happen in that case [15:21:36] either the radar register should be left untouched [15:21:39] or be set to 0 [15:22:08] it probably doesn't matter that much [15:22:12] set to 0 -- the SHINCs and SHANCs are going to happen, so it will either become 0 or garbage [15:22:28] I think? [15:22:31] probably 0 [15:23:03] ....actually maybe I'm wrong [15:23:17] LVDC is pushing AGC knowledge out of my brain :D [15:23:23] I know the feeling :D [15:23:45] we actually already have RR only code that is setting the range to zero when it hasn't locked on [15:24:17] and in slew it cannot be locked on [15:24:51] let me just do a radar cycle in the simulator really fast. I think actually it will be untouched now that I am thinking about it more [15:25:03] but you shouldn't be messing with radar related switches anyway when the LGC is reading from them [15:25:13] not when it matters anyway [15:25:27] the behavior might depend more on RR/LR hardware than the LGC [15:25:35] maybe [15:28:02] maybe I am finding some procedure with some expected result if you switch from LGC to Slew while in V63 [15:28:13] with my update I get no 1210 anymore, it just becomes zero [15:37:44] if the register is left untouched then I have to change my code a bit [15:38:00] I guess how we previously handled it, it would have been left untouched [15:40:02] mostly in the case of the LGC asking for data, but the RR or LR are unpowered [15:40:35] unless we know the register is set to zero, I should probably try to change the behavior we had before as little as possible [15:40:37] I think it is left untouched [15:40:41] almost there with the hardware sim [15:45:12] yeah, so the thing with SHINC and SHANC is that they're going to be started by transformer-coupled inputs [15:45:33] the AGC is going to be pulsing RRSYNC to the RR to get it to send bits [15:45:43] but if it's not listening, SHINC and SHANC are not going to happen [15:45:48] and so the counter isn't going to change [15:46:29] I like that result, just have to change my new code a tiny bit. Thanks for checking! [15:49:29] sure thing! [15:50:48] back to the LVDA. the telemetry registers are now not totally broken. but lots of logic left to implement to get LVDA telemetry to work :D [15:53:23] sounds like it is complicated haha [15:55:44] by LVDA telemetry you mean telemetry from the LVDA itself? [15:55:54] or all telemetry, including LVDC, going through the LVDA [15:57:23] telemetry from the LVDA itself [15:58:14] I think LVDC telemetry is mostly working now because it bypasses the internal storage of LVDA telemetry and just clobbers the output registers directly [16:10:28] ah I see some discussion on Github [16:10:38] Ron having trouble with imagining inertial velocities :D [16:16:11] haha yeah [18:42:28] would acceleration-sensitive IMU drift need the AGC to be in some kind of average-g program for the compensation to work? [18:49:50] I'm getting no compensation at all for ADSRA or ADIA. [18:50:20] hmm [18:56:39] "During free-fall only the NBDX, NBDY, NBDZ are [18:56:40] the relevant coefficients and the routine is so ordered that only [18:56:40] these terms are calculated for the gyro compensation." [18:57:39] ahh [18:57:51] well that would explain it [18:59:48] ah yeah, it checks DRIFTFLG [18:59:54] the IMU compensation package code [19:00:17] it needs that to be 1 for it to do PIPA compensation [19:01:01] "Bit is set 1 when Average-G is terminated and also in P51/P53 before taking optics marks and in P52/P54 after completion of coarse align (if performed). Bit set 0 if IMU coarse aligned or caged, and when Average-G started" [19:02:23] uhh [19:02:41] it needs that to be... 0 [19:02:46] getting confused [19:04:10] but for your purposes, it seems like it needs Average G [19:46:31] night! [14:58:55] hey [15:05:04] hey Niklas [15:29:30] I'm pretty happy with the CSM IMU drift and compensation. looking forward to testing the LM [15:36:14] hopefully not different at all [15:36:26] IMU axes should be the same [15:37:50] that's what I'm hoping for. i will just throw all 9 rates at it and watch the log. probably will fly a landing as a test. [15:43:51] that would be ideal [15:50:25] +144 −209 [15:50:30] my radar interface fix [15:50:39] gets rid of a bunch of bad code, so I like that [15:51:21] while it's still not the Virtual AGC causing radarupts, it's now at least our own ApolloGuidance class, instead of RR/LR/VHF ranging directly [15:53:59] morning! [15:54:02] hey Mike [15:54:32] working IMU drift and radarupts, sounds like things are going well :D [15:54:41] haha [15:54:57] one case that isn't fixed is when you get a timestep too long while it reads radar data [15:55:12] I got that on Apollo 9 sometimes, with the LR spurious routine running [15:55:22] if I switch between CSM and LM that takes a moment to load [15:55:50] and what probably happens is, the LGC already wants to start the next radar data read before having gotten the first radarupt [15:56:33] that is also the cause of the V63 1210 alarm that made me do this fix. Just in that case the radarupt never comes [15:56:53] hmmm right [15:57:02] I think from what I read the RADARUPT happens about 90ms after the radar activity bit is set?! [15:57:20] that isn't super problematic timing, only with time acceleration it could be an issue [15:57:34] so I still think causing the radarupt in NASSP code is better [15:57:37] and not the Virtual AGC [15:58:26] I think that is correct, yeah [15:58:36] at least RR etc. only have to write their data to the AGC register now and not do the other stuff [15:58:42] interrupt, resetting the bit [16:37:57] ooooh, FPGA LVDC is multiplying and dividing numbers. that means it is making it quite far into the self-tests, possibly all the way through :D [16:38:16] what self tests? [16:38:29] and does it agree with yaLVDC so far? :D [16:39:03] https://github.com/thewonderidiot/lvdc_simulation/blob/main/self-test/self-test.lvdc [16:39:14] the fact that it is making it this far means it must haha [16:40:08] ah you wrote some self tests yourself? [16:40:12] or is this from the PTC [16:40:24] wouldn't help much with divide I guess [16:40:40] everything except for MPY, MPH, DIV, and EXM is from the PTC, with some slight adjustments where the LVDC is different [16:40:57] ah ok [16:40:58] and then those four and associated LVDC features I wrote myself [16:41:16] testing things like divide by 0 and such I guess [16:41:28] oh no [16:41:41] I know for a fact that yaLVDC would still fail such a test [16:42:00] it gets the correct results for valid divisions, but not for invalid divisions [16:42:16] which is even any case where the numerator is bigger than the denominator [16:42:33] well, either that or the hardware simulator would fail the test [16:42:50] all I technically know is that for invalid operations they get different results :D [16:43:59] I never had a divide by 0 in our LVDC, but there is a case where you would get a logarithm of a negative number which is undefined [16:44:06] caused a simulation crash [16:44:14] but the LVDC logarithm algorithm prevents that from being possible [16:44:40] I think that was one of the first things I asked about when you got the AS-206RAM listing [16:44:46] haha yeah I remember that [16:44:53] but essentially the EDD also has the answer. Just have to limit the input [16:45:15] it was basically a case where the rocket needs to spend more than all its mass (so not just propellant) to get the desired orbit [16:45:29] which can happen with early staging or engine failures and such [16:45:49] I still have very limited visibility into what the FPGA is doing. here's what I'm looking at right now https://i.imgur.com/soiUpP0.png [16:46:25] in this capture DATA[3] is connected to VOYV, which is only high during MPY or DIV operations. the fact that it is going high at all means it's making it at least to the MPY tests, and the fact that it is going high repeatedly means those tests are passing [16:46:55] haha, seems like a crude way to determine what it is doing [16:47:45] haha but it's a start! [16:48:07] it's not like I can reach in and look at the state of all of the registers, as useful as that would be [16:48:57] but now that telemetry is working in the LVDA, I should be able to write a simulation of the mod 410 digital multiplexer and stream LVDC telemetry words to my laptop [16:49:06] which will be a much more useful indicator of what's going on [17:13:59] did you look more into if it was possible for them to have a repeatable TLI simulation? [17:14:20] I don't think it is [17:14:26] based on G.TERM [17:14:48] unless Ron has figured something out [20:47:23] night! [15:37:49] morning! [15:43:55] hello hello [15:45:01] found a GSOP error! [15:45:10] oh? [15:45:11] it doesn't say to take the unit vector of a vector [15:45:25] unforgivable :D [15:45:26] but I need to [15:45:32] gave me bad AOT angles [15:47:48] compared to the Programmed Guidance Equations [15:47:59] has the unit vectors of course [15:48:35] of course [15:48:58] but Norton also reviewed the GSOPs and got very angry about mistakes in them [15:49:07] they managed to get one by him :D [15:49:33] I guess it is thanks to Norton then that there almost no errors haha [15:53:42] hey guys [15:53:56] yo [15:55:19] hey Matt [15:57:17] so I've completely convinced myself that our LVDC schematics are outdated for EXM [15:58:07] I can get the correct behavior easily by adding one more input to an exisiting gate in the REI latch, and adding a new gate to the RED latch [15:59:03] and when I do that... it's hard to judge by the waveforms on the oscilloscope, but I think I am having a successful AS-512 launch that lasts for about the right amount of time [16:00:37] can you not look at e.g. the state of some memory addresses at the end of the run? [16:00:49] nope! [16:02:33] why not? :D [16:02:55] because it's trapped inside this chip and there are no debug tools that can show the contents of the chip's BRAMs to me lol [16:03:40] I could do it if I wrote a verilog simulation of their laboratory test equipment for the LVDC, and then made an interface between that and my computer [16:03:45] but that is another huge pile of work [16:04:52] so I'm going to keep going down the happy path and get the telemetry stream running, so I can watch all of the telemetry numbers as it goes. that is going to be significantly faster to put together than a debug tool [16:05:10] I see [16:10:40] yeah being able to capture all the LVDC telemetry will make it very clear what is going on [16:21:29] maybe tonight? I don't *think* the mod 410 should be too hard to simulate [16:27:53] starting to read about the non-repeatable simulation [16:28:17] seems like they just switch the platform to inertial and let it measure gravity as acceleration? [16:28:39] And then the LVDC software also calculate that gravity vector, which should cancel each other out nearly exactly [16:29:13] doesn't seem very exciting to try [16:30:34] maybe for the other interfaces [16:30:37] switch selector etc. [16:30:53] it also disables the automatic time base sequencing [16:31:08] so it needs external signals [16:31:10] I tried to use it, but it won't even launch because it is expecting external discretes to be applied [16:31:19] yeah [16:31:22] liftoff [16:31:58] but yeah I do want to get it working eventually [16:32:07] I don't know how useful this mode is, because then we might as well jump to simulating everything for the flight mode already [16:32:09] but I will probably keep the "platform up" bit off [16:32:53] it's useful for doing things in stages, because it is configurable unlike repeatable [16:32:58] oh if the platform is not up, will it run this mode at all? [16:33:22] it will run the mode, but it won't try do do that gravity vector thing. accelerometers will continue to work like in repeatable mode [16:33:31] ah nice [16:33:43] so I think nonrepeatable will be useful for progressively getting more working, by only enabling a feature at a time [16:33:45] so you need to feed it some discrete inputs and interrupts [16:34:06] yeah [16:35:21] then you really have to start simulating some Saturn stuff [16:35:43] the first few events can be run on a schedule [16:35:46] like the liftoff discrete [16:42:08] talking to the switch selector might get somewhat complicated haha [16:42:57] lol yeah [16:43:25] one step at a time :D [16:43:55] you tell me when I need to write a Saturn launch simulation [16:45:49] it will be a bit haha [16:46:00] good haha [16:46:26] I might actually try to get some of that laboratory test equipment for the LVDC working once I finish this initial repeatable mode stuff [16:46:41] because it would be handy to be able to inspect and modify LVDC memory, and single step through instructions [16:47:15] yeah, for sure [16:49:26] how large is a bin file of the software actually? [16:50:03] and does that include all the the "erasable" memory? [16:50:43] that is a funny question because to date, nobody has actually produced a bin file for LVDC software :D [16:51:41] Ron decided to skip the binary for yaLVDC. it instead processes a human-readable TSV file formatted like the octal dump at the end of a listing [16:52:01] ah [16:52:04] and for FPGA loading, I have to create a human-readable hexadecimal file [16:52:43] just wondering how we would create e.g. everything for an Apollo 16 launch [16:53:09] and if it would make sense or be realistic to have the things in the guidance presettings separate from the software [16:53:58] not from a binary point of view. the "erasable" and software are all intermixed, and the presettings are kind of mixed in with constants and things [16:54:22] so you'd probably want to load the binary, and then overwrite the presettings [16:55:17] what would we store in scenarios. With the AEA there is at least a clear part that is used as RAM... [16:55:33] otherwise it sounds like the AEA [16:55:41] oh that is a good question [16:55:44] well [16:55:48] the LVDC does have self-modifying code [16:55:58] so that would be a potential problem [16:56:04] hmm yeah [16:56:14] can be a problem for future us [16:57:20] our saving code could compare the state of the memory with the preflight file and only save modified memory [16:57:32] if that doesn't make saving super slow [16:57:37] but anyway, definitely far in the future :D [16:58:08] hehehe yeah [17:00:26] got me thinking if I should do this "compare line by line" with the AGS. I could probably make our scenario files 1000 lines shorter [17:00:55] because I am saving everything that potentially can be written to [17:01:55] definitely a tradeoff of scenario file size and saving/loading speed [17:04:22] I wonder if you could optimize it by flagging in the emulator which locations are modified [17:04:40] so then when you go to save, you only have to consult that list and save what's in it, instead of doing a big compare [17:05:39] sounds complicated and that would be one large array for the flagging [17:12:42] maybe not a great idea in the end. But potentially needed for the LVDC, so I'll keep it in mind. [21:41:33] night! [14:24:35] hey [14:26:20] hey Matt [14:31:11] I should take a break from this LM display and try to fix some bugs for once... [14:46:31] aha! [14:46:33] already fixed one [14:46:40] cue cards disappearing at CM/SM sep [15:40:29] morning! [15:43:20] hey Mike [15:45:39] trying to figure out if some cases of these 1210 alarms are realistic. Don't think you can help me with any simulation though, would need a simulated LR [15:48:39] like, commanding the LR to drive to position 2 with V60 twice [15:49:07] I see a luminary anomaly with a 1210, but it seems to only happen with R12 running, during powered descent [16:00:56] oh [16:01:02] it's not even radarupts causing that [16:01:11] so my update isn't even involved :D [16:01:16] need to check that though [16:02:59] makes sense I guess, why would it want to read LR data when you have only commanded the LGC to drive the LR to position 2 [16:21:35] hahaha yeah that does make sense [16:37:02] I think the LR is the only antenna I haven't messed with. how realistically does it work? [16:39:48] in its interaction with the LGC or in general? [16:40:09] interaction with the LGC, don't know right now. Getting 1210 alarms I don't see documented haha [16:43:59] the LR altitude, or I should rather say range, looks at the altitude directly below [16:44:27] it still transforms that to a range, depending on how the LR is pointing at the surface [16:44:45] but it doesn't not take into account that, where the LR is pointing, could have a different elevation than directly below the LM [16:44:49] doesn't take* [16:45:14] when I initially implemented all the complicated conversions for the LR data, I played with that [16:45:35] like doing a short iteration to get the correct range to where the LR beam is going/coming from [16:45:59] wasn't quite happy with the solution, but it's only really relevant for extreme terrain [16:47:03] you can do a Orbiter API call to get the surface elevation at any latitude/longitude [16:47:21] so it's possible to get the right place where the LR is pointing at [16:47:47] but as I said, didn't like my solution, and doesn't hurt us much not having that [17:21:43] I meant the antenna simulation itself, and it's interaction with the lunar surface. that sounds like a can of worms that doesn't need to be opened right now though [17:22:24] it's a [17:22:27] lem->GetAltitude(ALTMODE_GROUND) [17:22:40] and [17:22:40] lem->GetGroundspeedVector(FRAME_LOCAL, vel_lh); [17:22:46] and then lots of complicated conversions [17:22:52] but that's the two API calls [17:46:20] yeah, If I get the bright idea to mess with that, please stop me [17:51:05] I can imagine worse things to mess with [17:51:11] at least it is somewhat contained [17:57:12] it should probably be its own file [17:58:04] the LR? Yeah, it's one of the few things that haven't been moved out of there [18:00:46] https://i.imgur.com/LQzaAt1.png [18:01:07] I got telemetry streaming from my FPGA LVDC into COSMOS (https://github.com/BallAerospace/COSMOS) :D [18:01:29] now to add lots of packet definitions [18:09:48] seems a bit more advanced than the "these nearly random lines might mean it is making it through the self test" you had about 24 hours ago [18:14:18] hahaha just a bit [18:15:01] but this is why I was barging ahead with that assumption instead of trying to get enough GSE built up to be able to inspect memory [18:15:10] that will probably be a couple of weeks of work, vs. 24 hours :P [18:39:42] interesting telemetry program [18:45:02] it is reasonably widely used in the industry [19:24:13] thewonderidiot, are you just reading it in over a UART? [19:25:10] yep! I made a model of the Mod 410 multiplexer that creates 40-bit LVDC telemetry frames, and sends them over UART. I have python program listening on the other end that decodes the frames into tag and data, packetizes it, and sends it to cosmos over a socket [19:26:52] packets with the validity bit set are also discarded in the python program [20:41:14] night! [15:26:38] hello [16:43:03] morning! [17:57:56] hi Mike! [18:10:45] what's up? [20:13:52] getting stuck in meetings apparently haha [20:15:48] lol I feel that [16:41:33] thewonderidiot, does LVDC telemetry have subframes or like CSM/LM telemetry? [16:43:22] I'm not 100% sure what the superstructure is there [16:43:42] I'm operating on the 40-bit LVDC and LVDA telemetry frames [16:44:02] but I don't know if that got packed into a larger frame before transmission to the ground [16:59:42] I think it did [17:09:00] in block diagrams of telemetry flow it shows analog data from each stage going to the PCM DDAS, with separate digital data coming in, presumably from the LVDC/LVDA? [17:13:36] you're looking for the Mod 410 digital multiplexer [17:13:52] that's the one that sits between the LVDA and the PCM DDAS [17:18:23] it looks like the Mod 410 is one of many multiplexers [17:18:37]