[13:53:56] NASSP Logging has been started by indy91 [13:53:58] hey [14:03:47] hey [14:06:49] looks like I lost znc [14:16:48] the IRC thing? [14:33:04] yeah, had it setup on a raspberryPI at home as an irc bouncer [14:33:29] looks like I unplugged the pi this morning.... [14:34:35] well that's odd. [14:34:47] I can ssh into it [14:34:53] oh [14:35:04] hi, other me [14:35:26] that's better [14:37:00] haha [14:38:32] just had to restart it lol [14:40:08] always helps [15:31:00] I've been thinking about writing a very simple telemetry logger in python [15:57:16] sounds fun [15:57:37] CSM and LM both generate a lot of data, and not much is done with it [16:02:10] yeah, I've been able to read it off their respective ports [16:02:41] now I just need to do a bit of decoding [16:04:56] would our rtcc have any use for logged data? [16:07:04] sure [16:07:21] in reality the RTCC processed all telemetry for display [16:07:30] and there were some logging features [16:07:46] it also calibrated all data [16:08:18] there is a document on NTRS with calibration curves for CSM telemetry [16:10:24] or rather, it adjusted all telemetry based on calibration data [16:19:45] I don't know much about how logging and delogging, how they called it, works though [16:28:10] I can look into it [16:28:49] there could be some things about it in HSI-209462 [16:28:51] the nassp rtcc gets its data from papi calls right? [16:29:27] I should probably print that one :) [16:29:44] *oapi [16:32:44] when it wants to access Orbiter API stuff, yes [16:33:04] what I mean to say is: there is no TCP functionality outside of the LM and CSM output pcm streams, right [16:33:15] "papi" is also a thing, that's how some scenario save/load functions are called that are similar to Orbiter API functions, but are just part of NASSP [16:33:57] there is no framework in the RTCC MFD yet that receive telemetry via TCP [16:34:18] if it has to access the CMC or LGC or so it directly accesses its memory [16:34:35] we have the external groundstation application [16:34:40] have you tried that? [16:34:42] phone autocorrect is where "papi" came from [16:34:46] yes [16:35:05] looked through the code a fair amount [16:35:14] you can uplink from it [16:36:15] yeah [16:37:21] I can start with a simple logger, with the intent of only using the data for viewing in external applications, matlab etc, [16:38:12] but I think I'd want to make something more user friendly than "remember to start this python script" for a release [16:44:09] right. But it's probably best to first get any data logged. Already doesn't sound that easy [16:51:57] well, it's time to go. Will be gone until the 26th [16:52:17] I hope you have happy holidays [16:55:58] cya! [17:02:16] happy holidays! [17:05:58] Evening [18:22:39] hey Thymo [18:46:25] I see you're also making plans for telemetry stuff? [18:59:43] yeah, thinking about making a logger [19:01:28] I've been able to read raw data with a very simple python script [19:01:33] import socket [19:01:34] s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) [19:01:34] s.connect(('0.0.0.0', 14242)) [19:01:35] while True: [19:01:35] data = s.recv(1024) [19:01:36] if not data: [19:01:36] break [19:01:37] print(repr(data)) [19:01:37] s.close() [19:04:14] but I also want to make something that's useful to our rtcc and not just printing gibberish to a console [19:07:57] Ah nice. I've also been thinking about doing something with the telemetry. The current client we have is hopelessly outdated and I don't think anyone of us is willing to maintain it, I don't. Considering it's written in .NET. I want to do a rewrite in python with a Qt gui so it's also cross-platform. [19:09:52] yeah, updating it would be far too much of a pain [19:10:58] I don't think anyone here knows .NET either. [19:16:01] I certainly don't [19:16:52] the lock and parse functions in telemetryClient are about all I was looking to steal [19:37:45] looks like the TSTAP handles logging, but I'd have to read more. [19:38:27] s/TSTAP/TSTAP routine [19:49:20] hmm nope [19:56:58] might just be for report generation, or SMEK events [19:57:06] have to read more [20:39:52] maybe the new python client could be a kind of pyMSFN [17:32:03] morning!