[13:50:51] NASSP Logging has been started by n7275 [13:50:53] thewonderidiot https://github.com/orbiternassp/telemetryClient/blob/27850ac1785a104c92ad1d4522d24534d66d9854/Form1.cpp#L98 [16:41:38] ohhhh nice you're already doing this [17:29:55] oh that's quite old [19:23:35] In theory, it should work in the other direction too. If you had an "uplink" from the ground equipment, NASSP *should* understand [19:48:58] port 14242 for the CM [18:29:57] thewonderidiot, any luck with the telemetry client? [19:14:54] n7275, haven't had time to mess with it, but we'll probably be messing with the PCM again tomorrow [19:25:03] oh I do have a question about it when you've got a chance [19:26:14] https://github.com/orbiternassp/telemetryClient/blob/master/Form1.cpp#L4543 the frame count goes from 1-50, so I'm not sure how these checks for frame 0 get hit [19:26:31] framect gets set here: https://github.com/orbiternassp/telemetryClient/blob/master/Form1.cpp#L1921 [19:26:53] should that switch be on framead instead? [19:31:37] oh no nevermind that's LBR [19:31:45] so does CO2 partial pressure not come down in HBR at all...? [19:33:54] nah, that's 10A3 which should come down in word 116 [19:34:23] but word 116 in the telemetry client is "SCI EXP #11" [19:34:35] so I guess my question really is, how does that work [19:44:33] this is where our CSM code sends it: https://github.com/orbiternassp/NASSP/blob/ea8078da0ea8ed64f384baf0f8dbbf1dfb37d6de/Orbitersdk/samples/ProjectApollo/src_csm/csm_telecom.cpp#L3482 [19:44:38] hmmmm [19:48:14] oh, I remember [19:48:36] so the LBR stream generation and parsing are a bit weird in NASSP code [19:48:49] in the CSM at lease [19:48:53] *least [19:49:55] LBR *AFAIK* should just be a list words with no subframes [19:50:10] but we inpliment it with subframes [19:50:15] https://github.com/orbiternassp/telemetryClient/blob/27850ac1785a104c92ad1d4522d24534d66d9854/Form1.cpp#L4544 [19:50:26] that *should* be the same offset form the sync words [19:50:37] just with the code being weird [19:51:40] but that has an offset of 61... [19:52:43] Nik and I have definitely found some things that needed fixing in the past [19:53:17] I mean for HBR though [19:53:32] it looks like the telemetry client is expecting 10A3 to not come down in HBR [19:55:36] but our PCM does appear to be sending it down in HBR. I have 10A3 written down as being controlled by J6 pin M [19:59:54] https://github.com/orbiternassp/telemetryClient/blob/27850ac1785a104c92ad1d4522d24534d66d9854/Form1.cpp#L2679 [20:02:23] oh duh, these words are 0-indexed and the table I'm looking at is 1-indexed [20:02:57] so it *should* be picking up data, but it's not showing up [20:02:59] hmmmm [20:03:37] okay same question for that line then [20:03:48] framect goes from 1 to 50 in HBR, right? [20:03:56] display( data, 10, TLM_A, 3+(framect*3) ); [20:04:05] the comments say 10A3, 10A6, etc. [20:04:11] but that math is going to calculate 10A4, 10A7, etc. [20:04:28] er no [20:04:37] it's going to skip 10A3 and just do 10A6, 10A9 [20:05:55] should it instead be [20:05:59] display( data, 10, TLM_A, (framect*3) ); [20:06:01] ? [20:07:13] it could be that wrong have yet another off-by-one bug here [23:33:52] wow, reading what I said earlier, it makes no sense at all to me. [23:35:04] thewonderidiot, I believe you are correct. I think we have it wrong on both ends so we haven't noticed. let me see if I can compile this project still [23:51:08] aha! an offsetting error on both sides makes sense :D [05:49:27] thewonderidiot: https://github.com/orbiternassp/telemetryClient/pull/9 [05:50:00] Niklas has some trick to rebuild this (probably a working install of VS2010) [05:23:25] thewonderidiot: try this: https://github.com/orbiternassp/telemetryClient/pulls should be rebuilt properly now [06:19:01] err, hang on [18:45:10] n7275: nice, will take a look! [18:47:02] in case it's useful at all, here's a set of raw frames captured from the real PCM that I saved off as test data: https://pastebin.com/raw/eTcXh74R [18:47:31] most of the digitals are floating high, and most of the analogs are floating low at 0V (0x01) [19:10:13] I see another problem with NASSP's PCM [19:11:06] NASSP's subframes are calculated correctly...but the frame address starts at 0o300 not 0o301 [19:13:28] even though we say it does in the code comments [19:15:51] thewonderidiot the text in some of the text boxes is a but weird because of some kind of unicode/windows nonsense. [19:16:27] \s\but\bit [01:02:11] thewonderidiot, what does the frame address look like in LBR [22:46:00] n7275, I've modified my FPGA design to be able to lock onto either HBR or LBR from the PCM, so hopefully I should be able to capture some real LBR data next restoration session [22:46:32] looking at NASSP, I think the LBR stuff is handled slightly incorrectly -- or at least it's implemented very confusingly [22:46:48] void PCM::generate_stream_lbr(){ [22:46:49] unsigned char data=0; [22:46:49] // 40 words per frame, 5 frames, 1 frame per second [22:47:01] LBR only has a single 200-word frame that comes down once per second [22:48:59] thewonderidiot, we do it correctly in the LM, not sure why our csm lbr is implimented like this haha [22:49:04] and as a result there shouldn't be any logic on the frame number because those 200 words are of a fixed format that's the same for every frame [22:49:24] maybe Dan remembers [23:23:24] very curious [23:23:45] the frame format is laid out in 5 rows of 40 in the CSM systems handbook [23:24:01] so it may have just been lack of info + misinterpretation of that table