Jump to content

[WIP] Telemetry Radio


woodywood245

Should there be ratty data right before loss of signal?  

11 members have voted

  1. 1. Should there be ratty data right before loss of signal?

    • Yes
      8
    • No
      2


Recommended Posts

A Telemetry Radio is an idea I've had for quite a long time: specifically a way of transmitting telemetry data from a spacecraft to the ground like Telemachus, but with the line-of-sight and range restrictions of RemoteTech. I started out with a grand and somewhat complex system, but eventually I simplified it heavily and broke it down to this: a simple data server on one end and a receiving client on the other. Things are nearly at the point where I'll be making early releases so you can see what's what, so keep an eye out over the next few days.

At the moment, the server is a TCP server that establishes itself at the IP address and port listed in the antenna config. At the moment, the mod also requires RemoteTech. The mod's DLL actually references RemoteTech because it uses the RemoteTech.API class to gather connection information. I've tried getting to this class via Reflection. If anyone has any advice on how to get to this class through Reflection, I would be very thrilled.

At the moment, there are two clients, though only one of them is up-to-date with the latest protocols. The big one is a NASA Apollo Mission Control-style client implemented using WinForms (so expect it to work in Windows only). It has all of the flight controller stations (see the gallery below), with lots of plans and hopes and dreams. The other is a very stripped-down client that simply takes the data it gets and saves it to a CSV file. The second isn't a priority at the moment, so it isn't currently functional, though when it is, it should work in Linux and OS X, as it's a console program.

Javascript is disabled. View full album

Pros

  • Transmits telemetry approximately every quarter second.
  • TelemetryServer can transmit raw binary, strings, or anything else you might want. My client programs only expect a specific structure.
  • Compatible with RemoteTech, which means that if your antenna loses power, goes out of range, or drops out of line-of-sight, you lose signal at the same time that you lose RemoteTech connectivity.
  • Very very expandable. If you want a particular or function value added, I'd be happy to try to accommodate you.

Cons

  • At the moment, RemoteTech is required. If I can find a way to get to the RemoteTech.API class with Reflection, I will write it so that you don't need RemoteTech. It will only be highly recommended.
  • At the moment, there is no control of the craft from any client program. The server does not have an uplink capability right now. However, there are plans to change this (note the ABORT button on the BOOSTER station).
  • The Mission Control style client requires that you're running Windows.

TO-DO

  • Finish all mission control stations
  • Get into RemoteTech.API class with Reflection.
  • Create at least two antennae.
  • Add some shine.
  • Add uplink capability.
  • Delay data transmission based on RemoteTech delays.
  • Setup bulk transmission of recorded data after acquisition of signal.
  • Set limits on how much data can be stored.

DONE

  • Standardize transmission protocol.
  • Record data onboard vessel during loss of signal.
  • The INCO (Instrumentation and Communications Officer) station now allows the user to record telemetry to a CSV file.
  • The PAO (Public Affairs Officer) console now semi-functional. Certain flight events and mission control events are recorded by the PAO console automatically. The PAO console also offers the ability to add PAO commentary.
  • Data transmits fine across networks. Made some changes that helped it along.

If you're interested in taking this for a test drive, helping write code, or even make a model or two, I'd appreciate the help!

Source: https://github.com/griderd/SpacecraftTelemetry

Edited by woodywood245
Updated To-Do list/Done list
Link to comment
Share on other sites

Hey, that's pretty cool.

How does the TCP protocol work? What I think would be cool, is if it's an ASCII (telnet-style) protocol, it would be really easy to write linux scripts that could log the output, run it through some graphing tools, etc.

The server can transmit pretty much anything from raw binary to UTF-8 strings. Originally, all of the data in my client-server setup was transmitted via strings in key-value pairs. However, the more complex the information got, the more complex things became when trying to interpret the data. For example, I wanted to be able to transmit resource information related to each part in the vessel. Eventually I decided that it would be easier for me to use a serializable structure that can be deserialized on the client side. I'm not entirely happy with this solution either, as raw UTF-8 transmissions are preferable for the reasons you mentioned. In the future, I'm hoping that I can switch between protocols to support that type of data. However, at the moment I'm focused on trying to get the mission client working.

Update: I've added a class that transmits non-collection data. I'll be testing it today. If it works well, I won't be making any modifications to the raw telemetry client. I'll add an option to the transmitter in KSP allowing the user to switch transmission protocols.

Edited by woodywood245
Link to comment
Share on other sites

Yeah, TCP is a transport layer protocol. Telnet is an application layer protocol. It's up to the client software to interpret the data that's being transmitted. I only wanted to get the data out of KSP, and TCP seemed the easiest way to do it given the limitations of KSP's IO library.

Link to comment
Share on other sites

TCP isn't a telnet-based protocol like SMTP or HTTP. But TCP is only used for routing packets of data, and the data itself can take almost any form that can be expressed digitally.

Yep, SMTP/HTTP/Telnet are all carried via TCP. I think everyone here understands that. I was asking what application protocol (or what it might be styled after) the mod was going to use. Technically "layer 5-7" (depending on how you look at it) in the OSI model, rather than layer 4.

For instance, JSON, XML, serial logging, etc, are all potential formats.

I just think it would be silly to use something like SMTP. ;)

Edited by NecroBones
Link to comment
Share on other sites

Yep, SMTP/HTTP/Telnet are all carried via TCP. I think everyone here understands that. I was asking what application protocol (or what it might be styled after) the mod was going to use. Technically "layer 5-7" (depending on how you look at it) in the OSI model, rather than layer 4.

For instance, JSON, XML, serial logging, etc, are all potential formats.

I just think it would be silly to use something like SMTP. ;)

For right now, the main protocol is a serialized structure: https://github.com/griderd/SpacecraftTelemetry/blob/master/TelemetryServer/TelemetryData.cs

I used to use a raw data specification, the basics of which can be seen here. I'm in the process of re-implementing that as a possible alternate protocol. There is no particular protocol set in stone, and I'm willing to look at any possibility. I considered both JSON and XML for a time, but the downsides outweighed the benefits for the beginning of the project.

Link to comment
Share on other sites

Sometimes simple is best! ;)

I used to log data from a small weather station kit, which had a serial port on it. It would just output a line of data every time it received an update from one of the sensors, which were all on different schedules. So a script would have to be able to differentiate the different sensor lines in the output, and associate it with a timestamp on its own, but from there you could graph it or just log it, or whatever.

Logging/graphing/etc can be fun little projects for anyone with a little programming experience, or willingness to learn.

Link to comment
Share on other sites

Yep, SMTP/HTTP/Telnet are all carried via TCP. I think everyone here understands that. I was asking what application protocol (or what it might be styled after) the mod was going to use. Technically "layer 5-7" (depending on how you look at it) in the OSI model, rather than layer 4.

For instance, JSON, XML, serial logging, etc, are all potential formats.

I just think it would be silly to use something like SMTP. ;)

BTW, I apologize if this looked like my tone was shifting to A-hole mode. It wasn't my intent, but on re-reading I see it could look that way. I was just going for clarity. ;)

Link to comment
Share on other sites

BTW, I apologize if this looked like my tone was shifting to A-hole mode. It wasn't my intent, but on re-reading I see it could look that way. I was just going for clarity. ;)

It's fine, I understood what you were going for. I even had a momentary mental image of trying to code the telemetry to be sent via email. :D

Link to comment
Share on other sites

Yep, SMTP/HTTP/Telnet are all carried via TCP. I think everyone here understands that. I was asking what application protocol (or what it might be styled after) the mod was going to use. Technically "layer 5-7" (depending on how you look at it) in the OSI model, rather than layer 4.

For instance, JSON, XML, serial logging, etc, are all potential formats.

I just think it would be silly to use something like SMTP. ;)

I've designed a "formal" protocol by which the data will be transmitted, so I can support multiple formats going in both directions. All data is transmitted and received in the format below:

[table=width: 500, class: grid, align: left]

[tr]

[td]Byte Range[/td]

[td]Value[/td]

[/tr]

[tr]

[td]0-4[/td]

[td]ASCII value "begin": 0x62, 0x65, 0x67, 0x69, 0x6E[/td]

[/tr]

[tr]

[td]5[/td]

[td]Protocol ID[/td]

[/tr]

[tr]

[td]6-37[/td]

[td]Reserved[/td]

[/tr]

[tr]

[td]38-41[/td]

[td]Data Length[/td]

[/tr]

[tr]

[td]42-n[/td]

[td]Data Segment[/td]

[/tr]

[/table]

This format is represented by the class TelemetryServer.DataBlock. I've also written a general Client class in the TelemetryServer DLL. This way, anyone who wants to write their own client can just use the existing system to pull data off of the TCP line.

The current list of protocols defined by Protocol ID:

0 - Raw (this is raw binary data).

1 - String (this is UTF8 text).

2 - TelemetryData (this is the serialized TelemetryData structure)

3 - CommandUplink (this will be the serialized CommandUplink structure. This is a planned feature.)

Being that Protocol ID is a one-byte value, I can support up to 255 different protocols, which is more than enough for anyone to expand upon.

Update: It occurred to me in my sleep that I should at a few bytes of reserved space just in case I need additional flags and parameters later. So I've tacked on a 32-byte reserved field.

Edited by woodywood245
Added 32-byte reserved field.
Link to comment
Share on other sites

The Public Affairs Officer console is currently in the works. The PAO will be able to record "voice" transcripts of mission control and capsule loops such as:

  • Air-to-ground loop
  • PAO commentary loop
  • Mission control loop
  • Onboard voice recorder
  • Combination of all above

The mod will generate things to put in each loop as different flight events happen.

Link to comment
Share on other sites

  • 3 weeks later...
Will you implement kOS integration? Like, to send piloting programs to the probes because of the signal delay?

I've looked into this a little bit, but I'm not sure if it's possible without jumping through too many hoops. I am planning an alternative if this isn't possible. I do want to have some kind of thing for GUIDO to do.

Link to comment
Share on other sites

  • 4 months later...

I'd love to take this for a test drive. I have been trying to get something similar going in KoS, with limited success. I'd love to sit in mission control and let a probe run and not know whether or not it is "alive or dead" "crashed or successfully landed" for the long seconds or minutes it takes for the signal to reach me.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...