Speed of values being displayed may be not realistic?

[nicolaskolbenschlag]

Actual behavior
This came up when considering the unit of the time-sweep indicator (#151). But is has to do with time-sweep only indirectly. If this is an issue, it does not come from the time-sweep itseld but more from the overall way of how data is processed and displayed in the frontend.

Expected behavior
Other oscilloscopes might (as I understood) display new data in their own speed, meaning a new div (pixel, respectively) in a fixed amount of time (unit: [time/div]). Also, Wieland said that our time-sweep should be unit time/div. But currently that is not what our oscilloscopse (and by this also our time-sweep) does.

Additional context
Changing this would require changing the whole way of how data is processed in the frontend (I guess).

[nicolaskolbenschlag]

Leon and me compared our ideas and agreed on how to proceed:

• Where we stand:

• The speed in which our oscilloscope plots in dependent on the frequency in which it receives packages
• This receive-speed is dendent on the sending frequency of the backend (which is the generator's frequency divided by 200)
• Hence, the display speed is determined by the backend. It is of unit "div per update" and not "time per div" (as it is supposed to be)

• Workarounds:

• Obtain the time per update and compute the time per div, as we know how many divs refer to one update (namely one pixel per update times time-sweep)
• Our ideas differed in how we obtain the time per update:

Option 1: Use a constant as we know the frequency of our generator (drawback: more unrealistic as it only works for our generator and no other "sensor")
Option 2: Compute the time per update empirically on update (drawback: computation overhead and very laggy even if only measured at every 10_000 update or so)

• Next steps:

• Go with the first workaround option
• Maybe implement second in backend after this was refactored (Data signal packaging - migration from Backend to Generator #165)
• Nice-2-have: fix the underlying issue: buffer received signals in backend and let the oscilloscope determine its (fixed * time-sweep) display speed

[nicolaskolbenschlag]

Current display speed computation:

• Expect number of updates from generator/backend per second (as constant = 10_000)
• From this, the overall width (1000 pixels) and the number of divs (=20), we can compute the expected time per div (without time sweep):

• time_per_update = 1 / 1000 s
• pixels_per_div = 1000 / 20 = 50
• time_per_div = time_per_update * pixels_per_div = 50 / 1000 = 0,005s

• This is divided by the delta variable derived at time-sweep calculation
• and finally converted into ms/div

[jandegen]

The displayed sweep speed still not matches the actual sweep speed.
The indicators display 5ms/div (with 1 div is one grid block)

The real sweep speed feals more like 1 sec for 2 div, but that's not an correct measure, more like gut feeling