Hi Eric

@VM: yes, VirtualBox hosted on a MacBookPro, USB passed through and started a local indiserver. Same issue as on the RPi.

I noticed the strange values during initialization. However, I also set them via the respective panel to which the camera responded. Also, the CCD panel seems to push the settings before an exposure attempt.

I'll update to the latest version as soon as possible and let you know.

cheers
Niko

I'm also looking into why there are 3 failures reported successively. While it is possible, surely you didn't click the expose button thrice so quickly...

@triple exposure: That only happens when clicking "Preview" in the CCD panel. If I click "Set" in the "Main Control" panel of the "Indi Control Panel" I get only a single error.

I updated to 'libindi1 armhf 1.4.1+r3194~201707111817~ubuntu16.04.1'
The new log is attached.
cheers
Niko

If he clicks "Preview" in Ekos and it fails, it attempts a couple more captures automatically so this is why.

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