[15:37:02] NASSP Logging has been started by indy91 [15:37:03] the S-IVB was just a few degrees off in yaw [15:37:04] ok ok, it is suspicously close to 50% [15:37:36] orbital velocity vector vs. airspeed [15:38:18] So I think I have to compensate for the 0.5 factor in the drag equation when using SetCW [15:39:33] and the CSM probably was just in a bad attitude for drag, but it should have the same issue [15:41:17] but I guess the legacy model doesn't use the dynamic pressure in its calculation [15:41:31] not the same number that the Orbiter API comes up with I mean [15:42:19] but instead does F = CW*rho*V^2*A [15:42:35] which is weird but oh well [15:43:32] I could of course use the airfoil model, but I'm having a bit of trouble understanding how to use it for a symmetrical object like the S-IVB or CSM [15:48:54] what atmosphere model are you using, out of curiosity? [15:55:18] the standard I think [15:55:21] Jacchia71-Gil [16:02:43] the reference area calculation for drag is also a bit weird in the legacy model, hmm [16:03:07] in 2D it's basically sin(aoa)*Area1 + cos(aoa)*Area2 [16:03:16] where the areas are defined in the cross section function [16:03:23] 12 and 26 m^2 [16:05:03] the result is a maximum area of 28.6 m^2 [16:05:09] at 25° [16:07:22] or rather 65° pitched up [16:49:57] morning! [16:52:34] hey Mike [17:03:06] hey [18:01:18] n7275, have you ever done stuff with CreateAirfoil? [18:18:14] not recently enough that I remember how it works, unfortunately [18:19:36] was working on a lifting body design circa 2018, and that's probably the last time I looked at it [18:21:23] you can have two orientations with it [18:21:29] LIFT_VERTICAL and LIFT_HORIZONTAL [18:22:14] for drag calculations relevant is that vertical uses the angle of attack (alpha) and horizontal the slip angle (beta) [18:22:26] you can get somewhat away with only defining one of them [18:23:35] but if you are e.g. 90° yawed to left or right then your angle of attack is still 0 [18:24:16] producing the same amount of drag as if you were pointing forwards [18:24:41] so for that it would be desirable to also define the function with the slip angle, horizontal [18:25:21] but I don't think that gives realistic results for all cases either [18:25:42] if you e.g. slip the drag area between the two airfoils [18:25:55] split* [18:26:29] like, pitched up 90° and yawed 90° [18:29:36] the slip angle has a singularity if you have the vessel point straight up [18:48:57] yeah, as I recall it's a very simplistic first-year-engineering-textbook-flat-plate-approch [19:12:14] the main problem in this case is really that it's optimized for aircraft and not cylindrical rockets [19:12:26] probably implemented that way with the Delta Glider in mind [19:13:04] there is also the option to let Orbiter calculate the area from the cross sections [19:13:22] like it does in the legacy aero model [19:13:48] that could be interesting so that the contribution of one airfoil becomes 0 instead of having a singularity [20:56:43] night! [14:41:34] hey Nik [14:47:16] hey [14:57:38] someone had asked about it on the forum, so I added the Apollo 7 retro attitude orientation PAD for the MCC [14:57:54] I don't even know if the RTCC could calculate it, but for the RTACF I even have the punch card format for that calculation :D [15:00:41] I'm not sure, but I think in the RTACF the only way to start some calculation was with punch cards [15:00:56] they had UNIVAC 1108s [15:37:09] punch cards are fun! [15:50:08] maybe we need a card punch MFD [15:50:38] you can set up an RTACF MFD that only works with punch cards :D [16:20:03] morning! [16:20:16] that sounds amazing lol [16:28:01] semi-related heres the end result of my experimentation with the hangle subroutine https://drive.google.com/file/d/1RTgwvtrgbAqHWXUxhgQVakQECyKqOqh4/view?usp=drivesdk [16:29:56] hah awesome! I've been considering adding a fanfold paper-like output to pyul [16:48:09] would be nice to have a free-software solution. I used Rich Cornwells listtape, piped into netcat, broadcasting to hercprt [16:48:37] I guess all but the last part is [16:50:13] the font is JuliaMono, which has a very 1403ish look to it [16:55:44] oh man [16:57:15] I might have to try that out [17:02:48] I tried it with the output of pyul, the only issue is that hercprt doesnt detect the page breaks [17:02:51] hey Mike [17:06:02] n7275, that listing looks great [17:10:21] yeah, do you know what I would have to feed it for the page breaks? is there a special character or something? [17:12:35] ohhhh there's a special form feed symbol [17:17:03] n7275, were you running pyul locally? if so I can show you what to change that might fix it [17:18:41] locally, as in not over ssh? [17:19:02] I meant, using your own output from it and not something I generated [17:19:02] because I am [17:19:18] oh then yes locally [17:19:48] https://github.com/thewonderidiot/pyul/blob/master/pyul/monitor.py#L64 [17:19:59] that line should just become: [17:20:01] print('\f', file=self._lineprinter) [17:20:05] I think [17:20:33] and it might just work [17:30:39] made the change and sent it to the "printer" [17:31:25] will have to wait until i get home to see if it worked [17:35:03] hahaha alright [17:42:36] ohhh actually [17:42:50] you might need to add to that print() statement: [17:42:53] , end='' [17:43:01] to stop it from generating a newline immediately at the top of the next page [17:43:17] so [17:43:17] print('\f', file=self._lineprinter, end='') [17:45:01] I may have to copy that out of the znc log later, but I'll give it a try [17:53:01] may not need that extra bit. [17:53:51] looking at the output in vim, theres a single '^L' between pages, which is the same is I have from listtape [17:53:56] we shall see [17:56:51] hmmm yeah okay [17:57:28] without the end='', the first line of the next page is on the same line after the ^L [18:01:36] okay, yeah, hard to tell from my end [02:28:13] thewonderidiot, https://drive.google.com/file/d/1-YAtG8oYTj9woVSrHBq8H2UmZq8aaqcF/view?usp=sharing [13:13:48] hey Ryan [13:14:13] morning [13:14:19] did that file work for you? [13:19:07] yes. worked great! [13:19:37] if all worked properly you shouldnt have noticed much :P [13:20:21] can confirm [13:28:35] you should have a working waste stowage valve and glycol in the cooling loops :) [13:34:31] nice! [13:36:02] my intent last night was to log a bunch of telemetry, but I got stuck on the "why is this port blocked when it doesnt look like it is" part [13:43:37] lol [14:42:04] hi Nik [14:46:11] hey [15:09:57] Orbiter gives half the density I am expecting at 298km altitude [15:21:20] at most altitudes it seems [15:25:47] oh. that's a problem. [15:25:58] explains the drag issue [15:27:30] it explains why I get about half the drag in the 10 hours of separate coasting I did with CSM and S-IVB [15:27:38] than I was expecting [15:28:17] NRLMSISE-00 gives 50% more drag [15:28:23] but still low [15:28:53] especially at 300km it seems to heavily depend on temperature [15:31:04] actually what I got relative to minimum area and CD of 2 I am currently using is a factor of 1.1 for the CSM and 0.45 for the S-IVB [15:31:18] the S-IVB has been holding a steady attitude so that should have been 1.0 not 0.45 [15:31:51] and that is based on varying the CD for a 10 hours coast period where I saved the initial and final state vectors [15:32:52] and I guess that means that the CSM should have a factor of 2.4. Probably because I've been at draggy attitudes a lot [15:33:13] although that seems a lot [15:35:12] I guess I have to invest some time into understanding what Orbiter does [16:43:08] morning! [16:53:40] n7275: that looks amazing! [17:11:55] hey Mike [17:25:40] what's up? [17:26:32] trying to understand Orbiter's atmosphere models [17:26:44] I'm getting half the density of the 1962 US Standard Atmosphere [17:27:18] Orbiter has two detailed models to choose from which should in theory be more accurate [17:27:52] could also be an Earth ellipsoid issue again [17:28:16] our Earth is spherical with the radius of the launchpad LC-39 [17:28:32] but maybe Orbiter is still calculating the density as a function of latitude [17:32:38] mmmmm [17:36:15] One of the things the RTCC and RTACF could do is take two state vectors that are far apart in time [17:37:03] and then propagate the first state vector to the time of the second one, with varying drag [17:37:19] I did that with my 10 hours of Apollo 7 coasting [17:37:29] got a drag factor of 0.45 for the S-IVB [17:37:54] if the density prediction is exactly right that should be 1.0, the S-IVB is still keeping the desired attitude [17:38:06] for the CSM I got 1.1, but I've been maneuvering around a lot [17:38:26] also fun to see is the uncoupled thrusting of the S-IVB APS [17:38:45] the CSM state vector prediction gets to less than 100 meters error [17:38:50] with the right drag factor [17:39:07] the S-IVB one is larger, probably because of the APS [17:45:40] I can confirm at least that Orbiter uses the altitude and not the radius for the density calculation [17:45:55] that is good for us as we use a different radius than the normal Earth in Orbiter [18:14:37] I did a quick search of the forum earlier, looking to see of anyone else and noticed anything odd with atmosphere density. nothing. [18:27:17] well I'm not really sure yet it's actually odd [18:27:38] the graph in one of the tech notes from martins seems to suggest a great density variance with temperature [18:28:40] I guess I'll work on verifying the Orbiter calculations in a MATLAB script or so [18:28:49] just for understanding it better [18:29:58] but I do find it weird that the density of the standard atmosphere models used in the RTCC, for all trajectory simulations, would be wrong by that much [19:03:45] yeah [21:09:41] night! [21:46:02] TBH I'm not surprised that no one has ran into issues with the atmosphere model. Is there any other mod modelling the level of detail NASSP is? [21:46:20] Don't think SSU is even worrying about issues like this. [15:12:37] hey [15:31:08] hey [15:41:41] you can actually write your own atmosphere models for Orbiter [15:50:39] yes. there's api support for it [15:52:56] I feel like the Jacchia 71 model is giving too low temperature, but I can't really prove it quite yet [15:53:07] would be nice if martins had the source code for that public [15:54:04] yes, it would :/ [15:54:08] and the temperature is then causing the density to be low [15:54:22] maybe there is an error in the calculation [15:54:51] but then I also seem to get weird temperatures in some cases with the other model, so I don't know if that actually is a problem [16:00:01] also always possible that some approximation in Orbiter isn't accurate for 1968 [16:00:40] very true [16:01:12] have you tried the NRLMISSE model? [16:01:57] NRLMSISE, rather [16:01:59] yeah [16:02:28] on average I would say it's about halfway between Jacchia 71 and 1962 US standard atmosphere [16:02:40] probably a bit closer to what I was expecting [16:02:51] closer than half [16:03:12] so that would be better to use I guess [16:03:26] it's not a consistent half of the expected value though [16:03:38] for some other missions I get closer [16:05:12] well that's perplexing [16:07:57] I mean, density is a function of altitude and the direction of the sun mainly [16:09:06] so any problem with the temperature calculation would be the direction of the sun [16:19:20] we could try feeding the same initial conditions into GMAT and orbiter and see if results are even close [16:21:48] yeah [18:53:38] hey Mike [19:57:20] Hi all [20:44:52] hey ggalfi [20:47:54] what's up? [21:52:19] ggalfi, how've you been. I haven't seen you in a while. [22:16:42] Fine thx. Reworked the CSM Optics visual part (made the reticle more conformant to the real design, and made the camera transformation consistent with the rules of geometrical optics). [22:18:06] However I've done something nasty as the optics viewport begins to jitter after a while (I guess it is due some sort of memory leak/illegal addressing). [22:18:44] If you want to have a look, here is the new code: https://github.com/ggalfi/NASSP/tree/optics [22:19:30] I don't want to submit a PR till I haven't found the cause of this jitter. [22:22:38] n7275: About I haven't been here a while: last week when I entered here on to this channel I got your message about my VC development back from March :) Just I didn't have clue on how to answer through this Guenter guy... [22:26:58] .tell ggalfi Like this! [22:27:39] .help [22:28:07] Oh, guess help broke at some point [22:28:53] Thymo, thx, I'm infinitely smarter now with this .tell statement! :) [22:53:47] .tell n7275 Just learned how to use our good old Pad Leader for sending messages. Thanks for your kind comment on my VC development back from March! :) [22:59:49] .tell indy91 I've made new CSM Optics reticle. It is rotating with shaft, as discussed, and the view is _not_ rotating with it now, which we haven't discussed, but it should be that way because of the rules of optics. Still have some occasional jitter in SCT and SXT views, I guess due to some bad addressing I made. I'll submit a PR when I find the [22:59:50] cause of the jitter, but till then you can see it, if you want to make some comment: https://github.com/ggalfi/NASSP/tree/optics [23:00:44] Bye all! [13:14:08] good morning [14:38:05] hey [14:39:50] I've just learned something that makes me feel better about the atmospheric density situation [14:40:32] for 299km, which is the altitude in one of my Apollo 7 scenarios [14:41:06] 1962 US standard atmosphere: 3.654 kg/m^3 [14:41:27] 3.654e-11 [14:41:48] 1976 US standard atmosphere: 1.957e-11 kg/m^3 [15:00:02] oh wow [15:05:46] so definitely closer to Orbiter [15:06:40] and I'm not just going by the instantaneous density, I've done the trajectory check with a 10 hour coast [15:06:57] so what I am wondering now [15:07:00] RTCC uses CD of 2 [15:07:12] but for both CSM and S-IVB it's actually somewhat higher [15:07:17] but actual density is lower [15:08:03] and right now I am using the CD of 2 for CSM and S-IVB. So maybe I just need to make that larger, more realistic [15:08:44] and I'll be closer to the actual drag then [15:08:56] with CD and density both being off kind of cancelling each other out [15:09:34] the RTCC did get the Jacchia density model at some point [15:09:52] not sure when, there is a RTCC Requirements memo from late 1970 [15:22:24] haha, there is a revision to the Apollo 7 operational trajectory that we don't have [15:22:33] and it does "The CSM orbital drag model is updated" [15:22:48] time for NARA Fort Worth to reopen... [17:05:57] haha, yep [17:34:25] I ran accross this the other day. https://celestrak.com/NORAD/documentation/spacetrk.pdf. Is this related to the RTCC propagation routines in any way? [17:38:31] that's the propagation methods for the two-line elements, right? [17:39:18] the RTCC had something like it, the Analytic Ephemeris Generator. But it's mostly based on the work of Brouwer, the stuff in this document on the work of Kozai [17:39:23] similar but mostly different [17:39:39] I never managed to implement the AEG properly [17:40:13] Ron scanned this for me a while ago: https://archive.org/details/68fm23images [17:40:17] uhh [17:40:19] wrong document [17:40:39] https://archive.org/details/68fm119images [17:41:08] but it has some errors and the equations are so complicated and diffiuclt to understand I need the document that preceeds this one to really be able to use it [17:41:42] but because the nonspherical gravity is weaker in lunar orbit I am using it for the lunar launch window processor [17:47:00] because the error from the thing I couldn't figure is not so great then [18:18:16] ahh, okay. [18:21:23] based on the same ideas though. Calculate mean orbital elements and propagate analytically to avoid numerical integration. [20:36:27] hi all [20:51:29] hey [20:51:37] I got your message [20:58:05] Were you able to test it? I'm curious that it's only me or you also got some random jittering in the optics view? [21:00:25] maybe I only got part of your message :D [21:00:38] I see that you put your branch on Github [21:01:07] I can test it if you want. I do not get any jittering in the current NASSP version though [21:01:46] the message I got from you got up to "I'll submit a PR when I find the" [21:02:28] :) ... I find the cause of this jitter, which happens occasionally in optics view [21:03:17] [00:59:49] cause of the jitter, but till then you can see it, if you want to make some comment: https://github.com/ggalfi/NASSP/tree/optics [21:03:38] Looks like your IRC client wrapped the lines so it didn't get included in the reminder [21:04:08] right [21:04:13] building the branch right now [21:04:17] Probably I made some bad addressing error or something like that [21:04:40] I think the code for the resolved mode should still be correct, right? [21:05:13] was based on some actual equations rather than the desired behavior [21:05:45] I haven't touched the mode logic. However, with the new view transformation, the resolved mode became really useful [21:06:05] that's what I thought [21:06:25] the function setCameraLOS is what I couldn't figure out when I tried to implement this myself [21:07:54] Yeah it is not perfect, because you need three Euler angles properly set, but with oapiCameraSetCockpitDir, you can only set two. [21:08:01] yeah [21:08:56] But luckily, trunnion angle is limited to <60 degs, so in the way I implemented it, it doesn't cause too large errors. [21:09:23] I am always impressed with your work but you do tend to add build warnings haha [21:09:33] conversion from double to LONG in this case [21:09:39] no big deal [21:09:49] but something to be fixed before getting merged of course [21:10:14] so when do you get jittering? Manual mode or CMC or... [21:10:57] I got it in manual mode (in P52) and it jitters only in the direction of trunnion. [21:11:12] ok, I'll try that [21:11:55] SCT looks nice [21:11:59] reticle* [21:12:07] It sometimes happens, sometimes not. Typical indication that I have done something nasty. [21:12:55] CMC optics drives differently, too [21:13:09] did you put in some of your CDU code or optics drive stuff? [21:13:22] I can already see jittering in the SCT view [21:13:49] No, not at all. What you see in my commit, that is what I have tested. [21:14:15] ok [21:14:20] I do get a lot of jittering [21:15:05] no chance I can mark with this [21:15:14] hurting my eyes a bit [21:15:40] Yeah, it is very bad. And I have no clue what can cause this. [21:15:49] OldPolar and OldAzimuth are not staying constant [21:17:22] Yeah, that is annoying, that setCameraLOS doesn't cause this, but something causing the polar and azimuth values to change. [21:18:27] But oapiCameraSetCockpitDir isn't called (or at least I cannot see it) at any other place. [21:18:49] I mean in SCT and SXT views, of course. [21:19:41] but not every timestep [21:23:50] interesting [21:24:02] switching to the split LOS view fixed the jittering for me [21:24:33] Both in SCT and SXT? [21:25:27] yeah [21:25:38] or rather switching to the split LOS and then back, probably [21:28:34] yeah, works reliably [21:28:41] I get the jittering at first [21:28:45] press V twice [21:28:47] and it's gone [21:29:14] Odd... [21:31:25] The strange thing, that I call the camera functions practically at the same places as the previous version, only with some different numbers, but somehow this change introduced this jitter, with this very odd dependency on split LOS switching. [21:32:11] I guess some bad addressing is happening somewhere, but I cannot see, where... [21:39:29] I also can't imagine it's something else trying to move the optics elsewhere [21:39:36] because it would happen on the same timestep [21:45:12] hmm [21:45:29] if I null the attitude rates with the PAMFD then the jittering also goes away [21:46:24] so the jittering might be caused by the optics actually driving, somehow [21:46:48] I cannot decide whether it is good or bad news [21:48:06] Optics shouldn't drive (the trunnion and shaft values aren't changing, that's what you can see in the debug string set by setCameraLOS function [21:49:17] uhh true [21:49:21] let me try that again :D [21:49:38] maybe I did something different [21:50:01] but I guess it would have been the CMC optics drive inducing the jittering [21:50:23] and it's still going with manual optics? I'll try again [21:51:10] Yes, I've seen it first, when I tried to set the crosshair manually on a star during P52 [22:02:38] the thing with the attitude rates being nulled was probably nothing [22:05:13] oh [22:05:30] switching to the external view with F1 also fixed the jittering [22:09:13] I have an idea [22:09:56] setCameraLOS is not a member of the Saturn class [22:10:03] and you are calling oapiCameraSetCockpitDir [22:10:21] I wonder if that makes a difference [22:10:28] I have called, but it is commented out now already [22:10:47] You can call it only on panel switching [22:12:52] Oops, sorry, I meant SetCameraDefaultDirection, because it is a member function of Saturn class (inherited from VESSEL I think) [22:12:53] something is surely interfering. It's not only jittering. It doesn't even point directly at the star [22:13:25] Yeah, it is pulled back to the center with a few degrees. [22:13:57] making setCameraLOS part of the Saturn class didn't change anything [22:19:22] There is another thing, I haven't mentioned it yet, but SetCameraDefaultDirection has a third argument, which in the original code was set to "true", and I have used it in the same manner, and when I looked for the cause of the jitter, I changed it to false. However the "true" setting is invalid (unused feature), but for some reason, the developer [22:19:23] of the original code set it to "true". Maybe there was a similar issue there... [22:21:27] probably hoped that it got implemented at some point [22:21:41] actually using the killrot function of the PAMFD did seem to fix it after all [22:21:45] I'll try again [22:23:17] I am slowly getting the feeling it could be an Orbiter bug [22:23:39] maybe it doesn't like this combination of SetCameraDefaultDirection and oapiCameraSetCockpitDir [22:23:47] or something is not initialized [22:25:34] sometimes it gets fixed by switching panels in a specific way [22:25:48] maybe it was rather that than killing the attitude rate [22:26:38] getting a bit late for me. I'll test this tomorrow a bit more [22:26:43] Yeah, I want to test something when I got back home from vacation tomorrow (today in CET :) ): there is function which sets a deadband for the camera to center it within that band. [22:26:57] Maybe that causes this. [22:27:17] I let you go sleep. Still you helped a lot, I think [22:27:28] Thx [22:28:42] looks like a very promising update [22:28:51] should be no problem to get merged once the bugs are fixed [22:29:29] "there is function which sets a deadband for the camera to center it within that band." do you mean a function you added or from the Orbiter API? [22:29:59] Orbiter API. CameraCatchAngle or something like this. [22:30:42] hmm ok [22:30:55] we'll see. I'm sure it's something fixable. Good night! [22:31:54] Good bye all! [09:24:00] . [10:27:38] good morning [10:28:37] I lost power last night, and missed the end of your. conversation with ggalfi. did you guys find the source of jitter? [10:33:32] no [10:33:45] I found a few weird cases that fix the jittering [10:34:00] it's not only switching on/off the split LOS [10:34:08] also switching to the external view and back [10:34:27] quite weird [10:38:30] Orbiter doesn't seem to dislike calling oapiCameraSetCockpitDir each timestep or something [10:38:34] doesn't seem to like* [10:44:55] but yeah, pressing F1 twice fixes it [10:46:31] which might or might not be an Orbiter bug. There is a bunch of NASSP code at work when switching views [11:21:08] hmm. strange. [11:30:30] weird we never had this problem before [11:52:25] we never called oapiCameraSetCockpitDir on every timestep [11:52:56] uhh [11:52:57] or did we [11:54:08] now I am confused [12:43:13] I hope ggalfi finds the issue, because I surely have no clue [13:29:06] I just looked at the diff, and I can confirm that I probably won't be much help with this haha [14:59:36] Weird. I keep getting random D3D9 client access violations [14:59:54] in the Orbiter2016 branch [14:59:56] sounds very familiar [15:00:50] oh this is strange [15:01:44] it just closes with no error message, but event viewer shows "Exception code: 0xc0000005" [15:02:34] sounds very familiar [15:02:40] I was testing out Igel's Vostok addon in Orbiter 2016 earlier, and the same thing happened twice [15:03:37] so maybe it's not even NASSP code to blame [15:04:43] Probably not. When it happened earlier, I didn't have any NASSP modules loaded, was in a different version of Orbiter, and D3D9 client [15:07:52] I'm going to make a forum post with offset values so someone who knows that code better can look at it. [15:39:34] I made CSM and S-IVB a bit draggier, not like the RTCC is expecting (with the wrong atmospheric density) but what the CSM Data Book etc. actually say. And now I am flying Apollo 7 again. Hopefully with a bit more realistic trajectory now. [15:44:50] Nice [15:45:36] I'm going to finish flying Apollo 7, and then probably fly 9 after you push your drag update [15:46:04] I'm using the rest of the mission to generate telemetry logs [15:49:54] what kind of telemetry logs? [15:51:18] I'd like to make a matlab telemetry processor/graphing utility, and then maybe a fortran IV IBM 7094 (only slightly anachronistict) telemetry processor [15:52:11] gathering data via https://github.com/n7275/pyNASSPtelemetry [15:53:44] ah right [15:53:58] I remember you and Thymo created scripts at the same time :D [15:54:12] my raspberypi3 keeps up just fine in LBR at 50x [15:54:15] haha, yeah [15:55:26] I showed you the document that describes how the RTCC processed telemetry, right? [15:56:14] oh, don't think I've seen that! [15:56:27] one of the IBM documents, not sure how useful it really is [15:56:45] I'm sure you have it, NTRS ID 19730062603 [15:57:26] starting on PDF page 370 [15:57:39] yes, you sent me the folder of those. I'll take a look [15:58:10] and we have the program writeups for some subroutines it uses [15:58:15] but they are very general in method [15:58:49] it's a lot of tables containing type and scaling for each telemetry measurement basically [15:58:59] and limits, for lamps on MOCR consoles [16:05:46] I'm sure we can make something that works from that. it would only be a question of how accurate to the original it is. [16:13:01] well for your application it might just be interesting to know how the RTCC did it [16:13:11] doesn't have to be the same I guess [16:57:58] I'm pretty sure I can get it structurally very close. I'm sure doing it the RTCC way will have some insights and may make some things easier. [17:04:32] makes sense [19:13:18] Hi all [19:17:35]