Telemetry Format in Object Provider

[evenstensberg]

Hi! Doing some work on the Yamcs plugin and have some questions about the format the telemetry need to be. From the tut, I've seen the telemetry registered as in the screenshot below:

---

---

With the Yamcs plugin, the types coming in from the Rest API is a bit different, and I'm getting some errors when trying to log stuff in the realTimePlugin/historicalPlugin because the telemetry data isn't fully cooperating yet:

---

If you run this branch you can see the telemetry getting logged in the console. My question is as follows:

Do the telemetry data need to be similar to the openmct-tutorial dictionary.json or is there some docs on that?

---

[evenstensberg]

Would be a bit of a problem to convert too, as not all the incoming data from Yamcs is the same as in OpenMCT. Also getting empty data blocks, dunno what to plot instead of that

[larkin]

@ev1stensberg

You will need to translate the YAMCS Parameter Info into an object understood by Open MCT, and you will need to translate the YAMCS Parameter Value into a telemetry datum. This is why this sort of plugin is known as a Telemetry Adapter. There may be some differences between YAMCS formats and Open MCT formats but most information should translate directly. If you have questions in how the data should be mapped, let me know.

The reason you're seeing empty data blocks is because you're requesting the wrong data (Parameter Values) when what you need is Parameter Info. In fact, you're making two requests: List Parameter Info and then List Parameter Values, but you don't need the second request.

Your YamcsObjectProvider must transform the YAMCS parameter info into a domain object with telemetry metadata. The telemetry metadata for values must properly describe the telemetry datums generated by your historical and realtime providers.

Your YamcsHistoricalProvider will need to make a YAMCS List Parameter Data request for historical data and transform the results into a telemetry datum-- a flat javascript object (no nesting).

Let me know if that helps or if you have any questions.

[evenstensberg]

Exactly what I was looking for, and I know that my question was a bit vague composed. Thanks for elaborating @larkin ! 💯

[evenstensberg]

FWIW -- Thought that the initial telemetry needed some initial data, when in fact it's just plot settings ( If I've understood correctly)?

Your YamcsObjectProvider must transform the YAMCS parameter info into a domain object with telemetry metadata.

Wouldn't it be better to use "List Parameter Info", when the information is the same?

for "Get Paramerer Info" you'd need two requests to figure out namespace and name, /api/mdb/:instance/parameters/:namespace/:name

[evenstensberg]

Basic functionality is up if you want to test @larkin . Need to change some of the incoming dataTypes and fix timestamps before its ready for a draft

[larkin]

@ev1stensberg List vs Get: makes sense.

The initial is metadata is used by plots, image views, time controls, etc. The providers get the actual telemetry values.

I briefly looked through your code, some things I noticed:

• For your plugin, you should allow the :instance parameter (as well as the YAMCS server URL/port) to be customized when the plugin is installed.
• You should be using a combination of the YAMCS parameter namespace and name as the identifier.key for a parameter object. The same name could exist in multiple namespaces, which would cause problems with your current implementation.

Feel free to open an issue on your repository and @ mention me (e.g. @larkin) and I can respond there with feedback.