search

jetperch / pyjoulescope_ui

Joulescope graphical user interface
https://www.joulescope.com
Apache License 2.0
85 stars 26 forks source link

Add relative time option to Waveform widget #220

Open mliberty1 opened 1 year ago

mliberty1 commented 1 year ago

Joulescope model

JS220, JS110

UI version

1.0.29

Your idea

The Joulescope UI 1.0 uses UTC time throughout. UTC is great for comparing events across a larger system.

With the 1.0 UI, the actual wall-clock time for an x-axis location is the base time plus the offset. Let's take an example:

https://github.com/jetperch/pyjoulescope_ui/assets/5393422/69afa2fd-b636-4d0d-ba1b-6590e9a7dc25

00:01 Press Play to start streaming
00:01 Initial base time is 2023-08-31T11:20:31+00:00, offset in ms, 200 to 700
00:02 Base time stays 2023-08-31T11:20:31+00:00, offset in s, 0.2 to 1
00:11 Base time now 2023-08-31T11:20:00+00:00, offset in s, 32 to 42
01:11 Base time now 2023-08-31T11:21:00+00:00, offset in s, 10 to 40

In the case where you zoom in, the base time adjusts so that the x-axis offset maintains sufficient display precision without taking up far too many characters.

This "jumping around" as streaming starts can be disconcerting for some users. Also, some users want to measure a known process. For this case, UTC time is much less meaningful than elapsed time. The Joulescope UI 0.10 supported elapsed time when viewing JLS views. It also supported relative time, relative to the oldest possible sample, while in sample streaming mode. The Joulescope UI 1.0 no longer supports these modes.

I propose the following improvements:

  1. A new Waveform widget setting, x_time_mode. with the following options: a. utc - Use a UTC time base with offset, like done currently b. relative - Use the first available sample as zero. The time base text should omit the data and time zone offset.

  2. A sample streaming option that completely fills the buffer with empty data at the start. This allows for the same right-to-left growth at startup that the Joulescope UI 0.10 had. It also will keep the base time and time offsets from "jumping around" as the initial data grows.

Does your idea concern a specific OS?

No - applies to all

mliberty1 commented 1 year ago

Some additional thoughts. Representing time is particularly challenging because the UI blends several similar but different things:

  1. Live sample streaming

  2. Buffered data (paused sample streaming)

  3. JLS recordings

    The following notions of time can make sense:

  4. Wall-clock time (UTC)

  5. Time relative to start

  6. Time relative to the first possible sample time in the buffer, even if not yet available

  7. Time relative to now

  8. Time relative to some event, like a trigger (upcoming feature). Note that (2) is a subset where "start" is the event.

Oscilloscopes only do (3) or (5), which makes it much simpler.