ASI cameras, armv7

doliometer

Thanks for responding. Here is what I get with new SDK (v1.18):
[2021-05-25T04:17:08.713 UTC DEBG ][ org.kde.kstars.ekos.capture] - Preparing capture job "/home/debian/Light/Light" for execution.
[2021-05-25T04:17:08.934 UTC INFO ][ org.kde.kstars.ekos.capture] - "Job requires 0.500-second images, has 0/1 frames captured and will be processed."
[2021-05-25T04:17:08.957 UTC INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.500-second image..."
[2021-05-25T04:17:09.191 UTC DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI290MM : "[DEBUG] StartExposure->setexp : 0.500s "
[2021-05-25T04:17:11.169 UTC DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI290MM : "[DEBUG] ASIGetExpStatus failed. Restarting exposure... "

Tech@ZWO

doliometer
Did you try ZWO demo in the SDK?

doliometer

One more thing: The ASI183MM will capture an image if the ROI is cut down to 256x256, but not if the ROI is 512x512. In fact at 256x256, the system will capture at integration times below 1 second. I checked down to 1/100 second.

doliometer

Sorry, I'm not sure what that is. I do see a "asi_camera_test.cpp" under "indi-asi". I will try to figure out how to run it.

Thank you.

doliometer

I have run "asi_camera_test" on the 290. Image capture fails with full frame, error "3". Image capture succeeds with <width height bin format> set to 512 512 1 1.

Thank you.

Tech@ZWO

doliometer
First you need to try your camera on Windows to make sure camera is OK.
Then please refer to attached guide and give us the log.

how-to-enable-asi-logs-on-arm.rar

142kB

doliometer

Both the 290 and the 183 work fine on Chromebooks (subject to Chrome OS lockdown of root partition), so there is no doubt that the cameras work OK. (I don't have a Windows machine.)

Here is the log generated by the 290, full frame at 0.5 second integration time.

asicamerasdk.txt

15kB

Tech@ZWO

doliometer
Please try to change USB traffic first.(start from 40)

doliometer

Could you give me a little more guidance? Internet search indicates that some ZWO ASI interfaces (Nebulosity, Sharpcap, Firecapture) have such a setting, but I do not see one in the INDI interface. Nor did an inquiry at the indilib.org forum elicit any guidance. There is an entry in ASIconfig.xml that refers to USB: FPSPercentageUSB2, but the default setting is 5*10⁷ so that could hardly be something to set to 40 it seems.

So I would be grateful if you could provide a little more explanation about what you are suggesting.

doliometer

Or, here's another approach. I could use Steve Marple's python-zwoasi to access the SDK.

In the examples script (python-zwoasi/zwoasi/examples/zwoasi_demo.py /) at github.com lines 71 & 72 read

#Use minimum USB bandwidth permitted
camera.set_control_value(asi.ASI_BANDWIDTHOVERLOAD, camera.get_controls()['BandWidth']['MinValue'])

Are you referring to either the BandWidth or MinValue parameters?

Thank you.

doliometer

Actually I had not looked at asi_ccd.cpp in the INDI. Could you possibly be referring to this parameter?

#ifndef LOW_USB_BANDWIDTH
if (mCameraInfo.IsUSB3Camera && !mCameraInfo.IsUSB3Host)
value = 0.8 * cap.MaxValue;
#endif

Vector

Hello doliometer,

I think you'll find that they are referring to the "USB Bandwidth" setting. If you are using INDI, you should find this for your ASI camera in the INDI control panel, in the "Controls" sub-tab. I've attached a screenshot of what it looks like for me to help you find it. I hope this helps!

doliometer

Thank you, Vector, I do have that setting and will try it out.

doliometer

Changing USB traffic ("Bandwidth" in Ekos) to 40 has no effect on either camera.

I'm attaching a section from the logs for the 290 where first a 512x512 image is successfully captured at 0.5 seconds, and second an attempt to capture a 1024x521 image at 0.5 seconds fails.

Please take a look and see if there is something else we can do.

Thanks.

asicamerasdk.txt

18kB

doliometer

Dear Tech support, I hope you can look at this a little more. This is the Beaglebone Black. It is a very nice SBC to have at a telescope: it is small, quiet, powerful, low electrical current draw, and it has an active user community and open architecture. Given that it works partially, I think there is probably some small adjustment you can make to your SDK to completely accommodate the Beaglebone Black.