Altair Hypercam 294C Pro stops producing images in Ekos

[SevenW]

Describe the bug Altair Hypercam 294C Pro produces no images after stopping image loop (twice) in Ekos.

To Reproduce

1. start indiserver, kstars, ekos, activate a profile with the Altair driver
2. Start Framing (in a loop) by pressing the double arrow icon
3. Stop the loop with the stop button
4. Remove the fits image pop-up
5. Repeat this two times
6. The third time no more image window popup appears while most og Ekos believes images are captured.

Expected behavior Proper response to stop looping. Ekos continous to produce images all night long.

Screenshots N/A

Desktop (please complete the following information):

• OS: Ubuntu 18.04 on a HP laptop
• Version 1.8.4 and 1.8.5 (latest today)

Log Files log_13-27-28.txt

Root cause analysis In a test environment I reproduced the problem several times. Among other the attached logfiles shows that Event 0x04 (EVENT_IMAGE) is still received after the CCD Stopped command is issued. Interestingly, if such an event remains unhandled, a new images can be captured and is properly handled, but after aborting an image capture twice, no further Event 0x04 are produced. Hence no images are downloaded anymore.

One more interesting observation is that when images are captured, and no more event 0x04 are produced a can disconnect and reconnect the camera in the INDI panel in EKOS/kstars, and then after the camera gets initialized again, a event 0x04 arrives before any new capture is started, as can be seen in attached logfile in line 743.

The unhandled event 0x04 may leave images in the DDR memory of the Altair cam, and apparently the CCD has some issues with this.

I have been looking into a way to abort a capture, and properly handling the 0x04 events from the camera. I investigated two strategies:

1. Handle the 0x04 event when capture is aborted by downloading the image, but not retaining it.
2. Handle the 0x04 event when capture is aborted by calling toupcam_Flush() method.

Both work and solve the problem. The second solution has the advantage of avoiding a unnecessary download. The downside is that the method occurs in the toupcam.h file, but is not mentioned in toupcams API docs. The first solution uses functions that are already part of the driver.

A pushed both approaches to my fork of this repository. Please take a look at both and let me know if I can prepare a pull request.. See: https://github.com/SevenW/indi-3rdparty/commit/3d41ba41e8e14461e9a6bc37f4bb77fd88bb661c and https://github.com/SevenW/indi-3rdparty/commit/bab6a0a74d7de37b8ffb5c01b076e9616c792849

[knro]

Bravo! Great report & analysis! I wish all bug reports were like this!

How about calling toupcam_Flush in StartExposure() ?? So before we start exposure, we make sure everything is flushed? would that work?

[SevenW]

Previous solutions:

1. Flush when event 0x04 arrives while no longer InExposure
2. Read image data from camera when 0x04 arrives when no longer InExposure I have tested the following two additional solutions:
3. Flush at StartExposure()
4. Flush at AbortExposure() Both work. So it may be a matter of taste.

I do not prefer solution 4. Although the camera keeps functioning as expected, the event 0x04 still arrives after the flush once in a while. The camera seems to handle it well, but could be a race condition risk.

Solution 3 works well. Downside is that the flush command is called a lot more then needed.

I think solution 1 is quite clean. Only flush buffers when we get an event 0x04 when the driver don want to handle new images.

Please share your insight

[knro]

Thank you! Where there any downsides to #3? Any slower performance? or stuttering? or any side effects? I don't mind #1 as well if that appears to resolve the issue.

There is another problem with Touptek/Altair cameras, but on Raspberry PI and they do not seem to handle USB bandwidth well so the 0x04 event never arrives. One way to resolve it is by reducing USB speed. This sometimes works, but not always. What always works is when the resolution is set to the lower one. At any rate, this is perhaps a discussion for another time.

[SevenW]

I have looked at response the time between the startexposure and the first event 0x01. I do not see remarkable differences between the different solutions. Stuttering is something that can't be observed. Even with millisecond shuttertimes, the framerate with this camera is over one per second if a use Start Framing in loop. It takes 0.46 seconds to download a frame. It is not like video. Do I miss something in the settings?

I am quite new in this world so I do not have a frame of reference on performance yet.

I intend to move to the Raspberry Pi. So I will experience the USB issues there. I hope it is workable.

I do not have a strong preference for a solution. I can prepare a pull request in the weekend. Just say 1 or 3. If not I choose :-)

[knro]

I am leaning toward #3 as it grantees everything is flushed before the next exposure, but I don't mind going for 1 as well. It's your call.

[knro]

Hello, is there any update on this?