-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Labels
Comments
Testing
|
7 tasks
@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? |
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) |
This was referenced Jul 19, 2021
Verified Fixed. |
Verified fixed. Testathon 8/3/2021 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 fromDate.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.
On activation the remote clock will
domain
field that has the samekey
as the active time system.openmct.telemetry.request
)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.The text was updated successfully, but these errors were encountered: