Yes, preview makes three attempts to capture a picture.

I was in contact with TIS. They said the camera can only stream, no single frame capability.
Is there a way to still use the cam for guiding? That's what I intended to use it for in the first place.

Niko

Given the log, I'd say there is room for single exposure as the controls are available. I'm still investigating the issue.
-Eric

So after (better) investigation, the device provides no control to switch from the auto aperture mode to the manual aperture mode.
This means the device would be restricted to the frame rates listed for each picture size (1/3s max in some resolutions).
I'll try to update the V4L2 CCD driver so that it chooses the closest frame duration, or at least uses the frame rate currently configured, but no promises it will be usable.
-Eric

Hello,

I pushed PR #299, which is an attempt to bypass manual/auto control.

On my DMK21, manually exposing requires first switching the manual/auto control to manual, then providing the manual exposure duration. If I leave the manual/auto control to auto aperture programmatically, the code will attempt to set the exposure, which in my case is inactive, and fail (though there is no error returned for that action...). However the capture will be started nonetheless, using a default duration, closest one maybe, or one that matches the frame rate configured in the Capture Options (I had 1/30s in my test, matches the closest frame rate to the duration I used). Note that on my DMK, this also pops corrupted frames, but the V4L2 driver is able to work around this and provide an correct frame.

On your DMK31, there is no control for manual/auto exposure. So I changed the code not to fail when trying to switch that to manual. Theoretically, the driver may then accept the exposure duration inside the boundaries it reported previously (the control might not be inactive in your case), or may choose a default framerate duration (if the control is still inactive). In the best case, you would be able to request up to 3 seconds as indicated by the boundaries in the logs, or to configure a frame rate in the capture options that may be suitable.

I don't know if my explanation is clear. I don't have a hardware to test that so it's kind of a blind attempt.

The accessory problem is that the PR doesn't build because a prior commit broke the OSX Travis check (Travis OSX builds were down yesterday). Thus I don't know when the PR will be merged and available on the ppa. @knro: how do we fix that?

Let us know how it goes,
-Eric

Hi Eric

I fetched PR/299 and made a quick test. The behavior is still the same , however, more information ends up in the log-file.
Please let me know if I should run further tests or provide you with more information that might help to solve the issue.
In any case, I'm very impressed to see how fast this is going and that the issue is taken seriously.
Niko

Mmh, I clearly made a stupid mistake... You have:And when starting an exposure:It is the same control that is referred to by these two logs. I removed one wrong nullptr test at line 841!
Let me push something more to PR #299. It's a good thing you can fetch and build!

In the meantime, have you tried the IC Capture software with your camera? Are you able to change the exposure manually with that software?
-Eric

EDIT: you may go ahead testing PR #299, I pushed the mentioned fix.

I did check general functionality with IC Capture last week. I didn't do any in deeps checks, I was happy to get a picture at all
I'm on vacation right now and don't a have Windows PC with me, so I can't do anything with IC Capture.

For good measure, I added the output of v4l2-compliance, if it's of no use please disregard.
Niko

and ... it works !!!!!

Many thanks for this remarkable example of open source software advantages.

cheers
Niko

I won't let you leave until you share a few logs to prove it Now that's a happy ending!
-Eric

Hi Eirc

here the log to prove it really works.
Thanks again
Niko

Exposures are indeed possible now, but I would advise you to make more tests:in the log, some controls say exposure is either 1s or 1/3s, and the actual frame says it waited 0.125s. So although this is encouraging, it may need tweaking to function properly.
-Eric

Hi Eric

I've found some time for testing this evening.
The camera does recognize the exposure settings send via ekos. I prepared a short sequence with exposures from 0.001 -- 0.060 s and plotted the mean pixel values over the exposure time. To me, it looks reasonably linear which is what I'd expect.

The log file seems to be a little messed up. When triggering an exposure, the log receives data from the previous exposure.
In this case, I took a 1 s exposure before the sequence start. Resulting in:from the 1 s exposure, followed bywhich belongs to the actual exposure.

I noticed that the "Gain" in ekos has no effect on the images, but I have to check that in more details and get back to you.

cheers
Niko