Jump to content


Poor FPS with ASI174MM on RPi4 + USB3


Recommended Posts


I've been trying to find a solution for this problem for several days now without success. The issue is that I cannot use a ROI larger than 1024x1024 in oacapture or firecapture running on RPi4 (4GB) when my ASI174MM is connected via USB3 port. At 1024x1024 ROI I get about 60FPS (not recording, just viewing). If I increase the ROI even a little bit, say 1024x1028, the FPS will be < 1 and I get a ton of dropped frames. Playing around with the USB Traffic setting does not help at all. Both oacapture 1.8.0 and firecapture 2.7b.5 behave like this. Things that I've tried:

  1. Different USB3 cables.
  2. Plugging the camera directly to the RPi and via a powered USB3 hub.
  3. Disabled WiFi, Bluetooth and the RPi is running headless without a HDMI display (I've read about some RF interference cases relating to this)
  4. Replaced the libASICamera2.so library files with the latest form ASI SDK (libASICamera2.so.1.20) for both oacapture and firecapture.
  5. Updated RPi software and firmware to the latest.

None of the above made a difference. What is interesting that I get better results if I plug the camera to an USB2 port on the RPi4. With USB2 I get about 14-15FPS at full resolution? Any ideas?


Edited by kbrown
Link to comment
Share on other sites

The ASI174MM  is a 1936 x 1216 camera.

ZWO quote some other resolutions:


I'm guessing that non-standard resolutions like 1024x1024 or 1024x1028 will take significant time to interpolate.

From oacapture, my emphasis added:

User ROI selection allows selection of arbitrary size regions if the camera supports it. 

But maybe I'm not understanding the subtleties of downloading ROI resolution versus full frame resolution.



Link to comment
Share on other sites

Yes, I have considered that and tried all sorts of combinations. Even at the native maximum 1936x1216 I get < 1 FPS via USB3 and just mostly dropped frames which is completely unworkable. Via USB2 this was 14-15FPS?!?

A new finding just now was that if I keep the vertical ROI at 1024 and play around with just the horizontal one, I can get to 1536x1024 at about 55FPS. But then 1600x1024 is barely working at all.

On my laptop (oacapture) I get something like:

  • 1936x1216 -> 103FPS
  • 640x480 -> 250FPS
  • 320x240 -> 466FPS
  • 1024x1024 -> 122FPS
  • 1536x1024 -> 122FPS
  • 1600x1200 -> 103FPS

It really feels like there's something wrong with the USB3 ports on the RPi4 or the libASICamera2 library. Going via USB2 shouldn't be faster than USB3!

Link to comment
Share on other sites

4 minutes ago, CedricTheBrave said:

there was a firmware issue that caused slow data speeds on USB3 with SATA drives I am not sure if it was eventually resolved or relevent but this link here refers to it https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931

Yes I saw that. It seems to relate to usb storage devices only. I tried it with my camera's vendor and device ids but it had no effect. Even dmesg didn't show the quirk was applied.

Link to comment
Share on other sites

7 hours ago, CedricTheBrave said:

is it any better if you are viewing through a monitor rather than vnc (or whatever you are using)

Thanks for the suggestion but unfortunately there's no difference between vnc or local display.

I did some more poking around. I compiled another program called Planetary Imager to see whether it's any better. It suffers from the same behaviour. Then I thought maybe it's due to the 32bit Raspberry Pi OS so I installed the 64bit beta version. Again no difference. However with Planetary Imager I'm getting these warning as soon as the FPS drops down to unusable:

WARNING - void ImagerThread::Private::thread_started() ASI error TIMEOUT: timeout (code: 11) on Capture frame (/home/pi/Documents/dev/git_repos/PlanetaryImager/src/drivers/zwo_asi/asiimagingworker.cpp:115)

I had usbtop running in terminal while this all was happening so I could see how much data was actually coming from the camera. While everything was working (1536x1024 ROI) the data rate was around 4000-5000 kb/s which is easy peasy for USB3. When the above warnings were coming into play there was barely any traffic at all. Feels like it's a problem with the libASICamera2 (at least with ASI174MM) for armv7 and armv8 since three different capture programs suffers from the same symptoms...

Would be great to hear if anyone has had better success with higher than 1536x1024 ROI with reasonable FPS using any ASI cameras? I have a ASI183MC Pro as well. Will try that next...


EDIT: Ok this is interesting. With my ASI183MC Pro I was able to get fairly stable 2.2FPS at 5496x3672 (BGR24)! And about 6FPS if I changed to RGGB8 mode. At 1920x1080 (RGGB8) I get a stable 70FPS! Go figure...

Edited by kbrown
Link to comment
Share on other sites

Pawel Soja at the INDI forum is definitely onto something here: https://indilib.org/forum/astroberry/8142-asi178-camera-performance-on-rasperry-pi-4.html

He has been developing an alternative library for ASI cameras and getting some impressive results. Unfortunately it doesn't seem to be in stable enough state for everyone. I managed to get about 51FPS at full resolution with his library remotely via INDI/Ekos/Kstars. However I did get quite a few random crashes as well. I didn't get this working with oacapture, firecapture or planetary imager though. Not quite sure if it's even possible without modifying the source code of those apps.

I shall jump onto the above thread and post my findings there. Hope this develops into something great!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.