Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement new "Remote Clock" #3983

Closed
akhenry opened this issue Jun 28, 2021 · 5 comments · Fixed by #3998
Closed

Implement new "Remote Clock" #3983

akhenry opened this issue Jun 28, 2021 · 5 comments · Fixed by #3998

Comments

@akhenry
Copy link
Contributor

akhenry commented Jun 28, 2021

Right now Open MCT supports a "local clock" out of the box for realtime telemetry operations. This clock ticks on a local time source (ie. a recurring setTimeout which just pulls the current time from Date.now()).

This approach only supports so called "wall clock" time, and does not support simulations or telemetry playback of historical or future time periods.

To support these use cases we need a new clock that ticks in real-time, just like the local clock, but which gets a timing signal from a remote source instead of using Date.now().

The new remote clock plugin should be configurable with a telemetry point from which to receive the time data.

eg.

openmct.install(new openmct.plugins.RemoteClock({namespace: 'something', key:'telemetry-key'});

On activation the remote clock will

  1. Use telemetry metadata to select the appropriate timestamp on the configured telemetry point to fetch time data from (it will be the domain field that has the same key as the active time system.
  2. Request the latest time using a historical query (ie. openmct.telemetry.request)
  3. Subscribe to the configured telemetry point in order to receive timing signals on an ongoing basis.

When a new telemetry datum is received the Remote Clock will "tick" with the latest time (as provided by the server) as ms since 01/01/1970 (ie JavaScript time).

Most of the logic in the RemoteClock will be the same as logic in the LocalClock. The only difference is that instead of a setTimeout the tick will be triggered by the telemetry subscription callback. You might consider creating a shared parent class that they both extend.

@jvigliotta
Copy link
Contributor

Testing

  • install RemoteClock plugin with an identifier (OR view an already installed one)
  • Look in the developer network tab to verify that there is a WS stream emitting time-based telemetry

@davetsay
Copy link
Contributor

@akhenry , will this also cover the current clock functionality so that the clock bundle can be replaced by this? Or, is this a new type?

@akhenry
Copy link
Contributor Author

akhenry commented Jul 15, 2021

This is a new type of clock, it doesn't replace anything. It's an alternative to the LocalClock (ie. it makes the Time API tick, it doesn't show the time)

@nikhilmandlik
Copy link
Contributor

Verified Fixed.

@kobe1104
Copy link
Contributor

kobe1104 commented Aug 3, 2021

Verified fixed. Testathon 8/3/2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants