Add ERT to log files

[rrieber]

F´ Version
Affected Component

---

Feature Description

ERT, or Earth Received Time, is vital metadata to any telemetered information (channel, EVR, file, etc.). AMPCS has two options for reporting/recording ERT:

1. For information that comes from an antenna, the antenna can report when the frame is received. In that case, AMPCS ingests the ERT received from a ground station.
2. For information that comes from another source, packets/frames are stamped with the local workstation clock. This information could come from the simulation (SSE), the testbed, or other local venue.

Rationale

This is required for better interpreting telemetry. E.g. diagnosing clock issues, delays, latency problems. Also used in traditional time correlation processes.

[LeStarch]

@rrieber given that our GDS is intended for lab operations does the fidelity of "ERT at the antenna" make that much difference? It is substantially easier to stamp ERT when the bytes are decoded....but that could be a fraction of a second later. @timcanham your thoughts?

GDS architecture in a nutshell:

1. "Antenna receives packet"
2. Packet sent through dispatch server
3. Consumer decodes packet (this is easiest place to add ERT

We could add ERT at the antenna....but it is a much larger change.

[rrieber]

@LeStarch: I must confess that I am a tad ignorant as to whom stamps data with ERT in a heritage ground system and how that gets tacked onto a missions data. Rather than roll our own solution based on hypothetical use cases, we might want to look at how AMPCS addresses this and replicate their solution. I can offer you some people to talk to if you want to run this down.

If we are in the realm of not letting the perfect delay good enough, then what you proposed might be sufficient for a vast majority of users.

[timcanham]

To flesh this out a bit more, it really comes down to a packet ERT. We have decomposed the GDS into "packet providers" (currently network and UART) and the core packet processing. @LeStarch I think the API for the packet providers just takes the packet data itself. Perhaps it makes sense to update that API to include an ERT (or an optional ERT). For the default network and UART ones we can just have them get the wall time and pass it in. IMHO @rrieber is correct - it should probably be the job of the provider (which could be a DSN adapter in the future) to add the ERT in the event packets are buffered in the system somewhere. @LeStarch Maybe post the API here as part of the discussion?

[LeStarch]

@timcanham @rrieber you describe the slightly harder solution. No matter. It is not that hard to fix.