Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

indi_rpicam unable to set shutter speed for long exposures in EKOS #271

Closed
cnieswand opened this issue Dec 25, 2020 · 12 comments
Closed

indi_rpicam unable to set shutter speed for long exposures in EKOS #271

cnieswand opened this issue Dec 25, 2020 · 12 comments
Assignees
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@cnieswand
Copy link

I am using a Raspberry HQ Cam on a PI 4B running Astroberry 2.0.3.
Running KStars/EKOS using the indi_rpicam driver does not allow me to select any reasonable exposure time. Whatever is entered I always get the same image, especially for exposuretimes larger than a second. I can never saturate the sensor by lengthing the exposure time.
I have cloned the indi-3rdparty git repository and can easily modify, compile and debug the indi_rpicam driver.
However whatever I do, there is no way to set the shutter speed of the camera correctly.
Increasing the gain gives saturated output on all color channels.
I also did a rpi-update with no success.

I have noted that the line in mmalcamera.cpp, where the shutterspeed is set, is already marked:

// FIXME: Seconds does not work completely ok.
status = mmal_port_parameter_set_uint32(component->control, MMAL_PARAMETER_SHUTTER_SPEED, shutter_speed);
MMALException::throw_if(status, "Failed to set shutter speed");

So I guess that this is a known problem but I do not see any issue regarding this problem.
Is there any progress?

@cnieswand cnieswand added the bug Something isn't working label Dec 25, 2020
@knro knro added the help wanted Extra attention is needed label Dec 26, 2020
@knro
Copy link
Collaborator

knro commented Dec 26, 2020

@lboclboc Can you please take a look at this?

@lboclboc
Copy link
Contributor

lboclboc commented Dec 26, 2020

I know there was problem with this earlier. Make sure you use the latest rpicam version. Im not sure what version astroberry is using.
It is also important to specify a gain parameter. Otherwise it is automatic and exposure time does not work well.

@cnieswand
Copy link
Author

Meanwhile I modified the code, set the camera to burst mode, set the CAPTURE_STATS_PASS just before setting the ananlog gain.

Result is stunning: Trying to create a 9 second exposure gives me on the first capture a 1 second exposure, all subsequent exposures are correct. I checked this by taking a picture of an analog clock. So it has to do something with the preview feature of this camera.

@lboclboc
Copy link
Contributor

lboclboc commented Jan 8, 2021

Hi, I have uploaded some fixes now, mostly made by https://github.com/QRainman, to my master branch https://github.com/lboclboc/indi-3rdparty that hopefully solves the long exposure problems. You are welcome to test this out.

@cnieswand
Copy link
Author

Unfortunately this does not help.
Assume I define in EKOS a sequence having 9 secs exposure time per frame. Whenever I start indiserver and "connect" indi_rpicam (compiled from your branch, fresh clone from today) the first exposure is 1 second long. All subsequent frames are 9 seconds ... until I disconnect and reconnect. Then it is again 1 second and all subsequent frames again 9 seconds.
I mean as long as I know, I can live with that "feature" ... but it is not nice ... also because the fits info in this first file is wrong, because it is generated from EKOS settings ...

@knro
Copy link
Collaborator

knro commented Nov 24, 2021

@lboclboc @cnieswand is this still an issue with the latest RPICam driver?

@lboclboc
Copy link
Contributor

Yes, sadly this is still a problem. I have not been able to find a solution for this yet.

@aaronwmorris
Copy link

I discovered another interesting behavior. Long exposures do work, but only if the first (throw away) exposure is requested as 2 seconds or longer. If the first exposure is 1s or shorter, none of the exposures will exceed 1s even if you request longer.

@aaronwmorris
Copy link

Correction, a 2 second throw away exposure allows up to a 6-7 second exposure. Taking a 7 second throw away exposure seems to allow the maximum exposure times.

@sajmons
Copy link

sajmons commented May 3, 2022

I can confirm that with INDi 1.9.5 and Kstars 3.5.8, taking first exposure at exactly 7 sec, solves the problem. All exposures that you take after that are corect.

Use following workarround if your exposure times don't work:

  • make sure that you are on CCD tab (camera icon) of EKOS
  • restart camera driver with a on/off button (right after camera dropdown)
  • set initial exposure to 7 sec and click camera button to execute preview
  • exposure times will now work as expected

I hope that this information is useful for devs to pin point the bug and fix it?

@simonachmueller
Copy link

simonachmueller commented Jun 22, 2022

I'm using indi_rpicam v.1.3 compiled from latest sources today, indi build from recent sources yesterday.
KStars 3.5.9 for Windows.

It seems like I can't set exposure more than 6 seconds (2022-06-22T20:21:32: [ERROR] Requested exposure value (7) seconds out of bounds [0.001,6])
And even if I set it to 6, in the indiserver -v indi_rpicam I see:

2022-06-22T20:16:22: Driver indi_rpicam: setExposureParameters(/home/pi/src/indi-3rdparty/indi-rpicam/mmalcamera.cpp:142): Failed to set shutter speed, requested 6000000 but actual value is 999776
2022-06-22T20:16:22: Driver indi_rpicam: setExposureParameters(/home/pi/src/indi-3rdparty/indi-rpicam/mmalcamera.cpp:144): shutter speed set to 999776

Does this driver support longer than 1 sec exposure or not?
UPDATE:
I tried the approach with a sequence as discussed about, but it does not help, each capture have 1 sec exposure time.

@sajmons
Copy link

sajmons commented Jul 18, 2022

According to this, we are getting fix for this problem soon! Yeeea!
028c59a

@knro knro closed this as completed Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants