If I let the waveform view run for a just a few minutes with 2MHz sample rate, the visual update rate of the view drops to about once per second. It’s not only the waveform view that is affected, though, as interacting with the menus is also affected. When I can eventually access the menu, doing View→Manage, and hitting the reset button for Oscilloscope fixes the update rate for some time, but it will eventually slow down like it had before. If I reduce the sample rate, the issue will still occur, but takes longer. I’m not trying to write any logs when this occurs (saw that mentioned as a potential slow down source).
Watching Task Manager while hitting the reset button, I see memory usage for Joulescope drop by 1GB. Doing so successively each time the issue occurs does not bring the memory usage down to any particular base level - there always seems to be some remnant memory usage (ex: first reset went from 2.2GB down to 1.2GB; next reset went from 2.8GB down to 1.4GB).
I don’t know Python, but my assumption is that there are old waveform view-related objects that should have been removed with garbage collection that are sticking around and are still being iterated through as part of a screen update process and hitting that reset button force-kills all of them.
I could not find this topic brought up previously, so I suspect its something specific to my setup, but I’m not sure how.
From the Joulescope About screen:
Version Information:
UI:1.3.6
driver: 1.9.4
JLS: 0.15.0
Python: 3.12.10 (tags/v3.12.10:0cc8128, Apr 8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)]
Platform: Windows-11-10.0.26100-SP0
Processor: Intel64 Family 6 Model 165 Stepping 2, GenuineIntel
Thank you