Command to push telemetry values

[rrieber]

F´ Version
Affected Component

---

Feature Description

Operators are blind to real-time telemetry channels that are configured to telemeter on-change where the change occurs when there was no communication (e.g. during radio boot, when no antenna coverage, etc.). Obviously, the channel values are present in the ComLogger files, but those are onerous to obtain in terms of the command to telemeter and the bandwidth they consume.

What would be awesome is a command (part of TlmChan?) to "push" the current value for all channelized telemetery. To conserve bandwidth, an argument to push only channels configured to telemeter on-change would be nice too.

Rationale

Enables efficient operator visibility into the current spacecraft state.

Note there are comparable features on SMAP, a less-awesome version on M2020, and I think there's a comparable command on Clipper (but I can't get to their command dictionary tool).

[timcanham]

Just so it's stated, the "update on change" part is only known by the components, not by TlmChan, so to selectively do it in TlmChan would require passing more information through the port call. An alternate way to do this would be to have some channel profiles defined in TlmChan that the ground could request a push of, and would be tuned for things like bandwidth.

[rrieber]

@timcanham A good point you make! My ignorance about the inner-workings of the code is front and center :)

[LeStarch]

I am going to close this as it doesn't mesh with the architecture. For those who need this functionality:

1. Could make the telemetry push "always" and use filtering or the TlmPacketizer to limit it downlink on command
2. Set telemetry in component as "always" and write a helper that only sends telemetry "on change" with a command that also sends it down.

[Joshua-Anderson]

@LeStarch is there a reason we wouldn't pass always/onchage state to the tlm component on telemetry write? It adds a byte or so of internal message overhead, but would allow the support of features like @rrieber is requesting.

For what it's worth, I second @rrieber's request - it's critical for operators to be able to dump telemetry state. Otherwise you could be blind to telemetry state changes within packets packets that got lost/delayed

[LeStarch]

We could do that....but the filtering is done internal to the component.....so I don't see what this adds.

[Joshua-Anderson]

My goal would be to add a command to TlmChan and TlmPacketizer that would send out that last received telemetry from all channels, regardless of always/on_change state. Thinking about it more, this could probably be accomplished without sending on_change/always to the telemetry component. I suspect buffering the last recieved telemetry value from all channels probably wouldn't be particularly memory expensive.

[rrieber]

@LeStarch What I'm hoping we have is a 1-command feature that dumps the entire telemetry state. I'll confess again that I have no clue how best to make that happen internal to FSW.

What @Joshua-Anderson proposes, buffering last sampled value in TlmPacketizer sounds ideal. I believe something like this is how other missions have implemented the telemetry architecture. Additionally, such a last sampled value opens up new features such as a high-watermark report (or also called a min/max report).

[LeStarch]

Yes, a command to send the last recorded telemetry again would be straight forward. In the case of telemetry that did not change, you would get the value with the oldest timestamp.

If a project wants to see the newest timestamp, they'd be required to use "always" telemetry and filter the on-chane themselfs.

[LeStarch]

@Joshua-Anderson @rrieber I believe TlmPacketizer can already send a packet on command. This would send the last seen values. Is this not sufficient?

[Joshua-Anderson]

That solves much of the issue - but a command for sending every packet would be nice. We would also need similar support in telemchan.

I think what we really need is to have a larger discussion on the fprime telemetry system architecture. Right now we expect folks to use one or the other, but there's been some good use cases for supporting both that should be considered.

[LeStarch]

Want to open a discussion on this? Note: nothing says you may only choose one. A Com splitter would easily allow both to run in-tandem. Then you could have a send-on-command packet engine and real-time engine.

Also, for the "send all telemetry" command, I am hesitant on this. It could easily stampede the radio on larger projects causing a "do not send this in flight" command. It would be a better process, I think, to have projects define a "critical telemetry packet" and then send that on command. It could theoretically contain all telemetry if you want it to.....but would for the users to think through the process.

[timcanham]

For what it's worth, on Gecko we were planning on a ComSplitter that would send telemetry to TlmPacketizer for the radio, and TlmChan for the ComLogger to storage.