ADALM2000: <0.1 FPS Oscilloscope on M1 Macbook Air

[NoRePercussions]

Environment:

• OS: Sonoma 14.2.1
• Hardware: M1 Macbook Air
• FW: v0.25
• SW: v1.4.1 (f4beeb1)

Describe the bug
The Oscilloscope commonly runs at >10s per frame.

OpenGL rendering is disabled to mitigate #1531.

Tested at plotting refresh rates 30 and 5.

To Reproduce
Steps to reproduce the behavior:

1. Open Scopy
2. Disable OpenGL Rendering
3. Connect to ADALM2000
4. Calibrate
5. Open oscilloscope pane
6. Run and try to measure anything

Expected behavior
The graph should not take 10+ seconds to render.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context

I do not have logs yet but will attach them when I have them.

[adisuciu]

The problem si related to using software rendering. Using OpenGL is the way to go for Retina displays .. did you have problems when enabling opengl with adalm2000 calibration, because they should be totally unrelated ...

[NoRePercussions]

Yes, when OpenGL is enabled it reliably crashes. If there is another issue about this, I'm happy to try to collect logs.

However, I think it is still a bit problematic that it takes so long to render with software rendering, even if it is at retina resolution. Additionally, most of the measurements during this time actually show up in the rendered graph. Perhaps something else in the render loop is causing this?

[AlexandraTrifan]

Hi,

Do you get any MacOS generated crash report when Scopy crashes with OpenGL enabled? If so, could you attach the information here?

Could you update the ADALM2000 firmware to the v0.31 or v0.32 version ( https://github.com/analogdevicesinc/m2k-fw/releases ) and try again with OpenGL enabled?

Thank you!
-Alexandra

[NoRePercussions]

scopy crash 2024-02-29.txt

There doesn't seem to be anything else in console. I can't change the firmware of the device unfortunately.

Additionally, I was wondering where Scopy writes session logs when those are enabled.

Would you like me to open a new issue for the crashes?

[NoRePercussions]

I'm no longer sure if this is related to OpenGL. I will experiment more. 1555 is reproducible with or without OpenGL, so it may be that I just got bad luck or bad methods when I initially tested if it was an OpenGL setting issue.

However, I think the render time this thread is about is still a problem, and I'm open to continuing to provide information on it.

[adisuciu]

We've tested the issue on our M2 Macbook in the office and this does not reproduce.

The show plot fps is a debug option, used mainly for development. FPS is a badly used term in this case, and it shows more like Buffers per second. Buffers per second is a measure of data rate which is constricted by framerate as well.

This being said, the correct way to test frame rate would be to disable triggering and letting data flow freely into the oscilloscope, then the only limiting factor for the data rate would be the frame rate of the plot. If there is a trigger activated, that trigger will drive the data rate.

Autotriggering means basically if no trigger occurs for half a second, force a trigger. Therefore the datarate with autotriggering would be 2 buffers per second. Normal trigger with a trigger every x seconds would give an 1/x buffers per second.

To test things out, go to the trigger menu and select INTERNAL(ANALOG) - OFF, make sure DIGITAL is OFF as well. The blue handle on the right representing the trigger level should disappear. When running the oscilloscope, the data should flow freely into the instrument, therefore having max FPS, assuming there is no underlying issue with FW 0.25 here.

Can you test this out ?
-Adrian