×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Read More...

Question about driver behavior for CCD Exposures - needed help for understanding.

  • Posts: 124
  • Thank you received: 28

Question about driver behavior for CCD Exposures - needed help for understanding. was created by Michael

Hi,
First of all, many thanks for all the work done so far to offer that broad framwork and applications for astronomy. I'm struggling a little bit with interfacing to an INDI server for CCD cameras and which messages the server (driver) is sending. Therefore I would like to compare the CCDSimulator with the ASI_CCD. The use case is just exposing and wait until finished. And I'm showing the message I receive in my APP:

First the Simulator:
[2021-09-05 12:07:56.658][T][ indiBase.py][ 738] SendCmd: [newNumberVector device="CCD Simulator" name="CCD_EXPOSURE"><oneNumber name="CCD_EXPOSURE_VALUE">3.001</oneNumber></newNumberVector][2021-09-05 12:07:56.824][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, CCD Simulator, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 3.0009999999999998899 ]
[2021-09-05 12:07:56.990][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, CCD Simulator, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 2.6710000038146972656 ]
[2021-09-05 12:07:57.990][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, CCD Simulator, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 1.6699999570846557617 ]
[2021-09-05 12:07:59.164][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, CCD Simulator, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.66999995708465576172 ]
[2021-09-05 12:07:59.660][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, CCD Simulator, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-05 12:07:59.752][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, CCD Simulator, Ok, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
My interpretation: I set the exposure to 3 s, then the driver starts exposure and send each second an update for the exposure time. During this the state is going to Busy. Last exposure time is 0 with state busy, then after a short time the driver goes to state OK. I do not get more than these messages. That's exactly what I expect, the minimum messages needed nothing more. The only point: I set the exposure on 3 seconds and got 3.000999 second in the first message back. No clue why.

Now the behavior of the ASI driver:
[2021-09-02 02:14:28.658][T][ indiBase.py][ 738] SendCmd: [newNumberVector device="ZWO CCD ASI1600MM Pro" name="CCD_EXPOSURE"><oneNumber name="CCD_EXPOSURE_VALUE">2.0</oneNumber </newNumberVector]
[2021-09-02 02:14:28.738][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 2 ]
[2021-09-02 02:14:28.739][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 2 ]
[2021-09-02 02:14:28.744][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 2 ]
[2021-09-02 02:14:29.736][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 1 ]
[2021-09-02 02:14:29.837][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.89899998903274536133 ]
[2021-09-02 02:14:30.038][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.79900002479553222656 ]
[2021-09-02 02:14:30.040][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.69900000095367431641 ]
[2021-09-02 02:14:30.137][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.59899997711181640625 ]
[2021-09-02 02:14:30.238][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.49799999594688415527 ]
[2021-09-02 02:14:30.338][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.39800000190734863281 ]
[2021-09-02 02:14:30.438][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.29800000786781311035 ]
[2021-09-02 02:14:30.539][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.19799999892711639404 ]
[2021-09-02 02:14:30.640][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0.097999997437000274658 ]
[2021-09-02 02:14:30.739][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:30.964][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:30.965][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:31.039][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:31.290][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:31.292][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:31.340][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:31.442][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:31.547][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Busy, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]
[2021-09-02 02:14:32.296][T][ indiBase.py][ 973] RecvCmd: [setNumberVector (CCD_EXPOSURE, ZWO CCD ASI1600MM Pro, Ok, 60) oneNumber (CCD_EXPOSURE_VALUE) 0 ]

I do expose only 2 seconds (OK, it's an log of an user of my app, then I see three times the s seconds plain (out of the driver I learned that there might be some retries necessary), the number is exact as the driver rounds it. Question: why are the retires starting the exposure (if that's the case) are sent also as messages ???
Now the following message count the exposure time down. During the last second, I have shorter intervals. What is the reason for this?
Then I see multiple message always showing the same state (Busy) and exposure time 0. So nothing wrong, but why sending these messages without having anything new to tell?

There is no critics about it or the implementation work already done! But to be honest: I could not understand it. Unfortunately my understanding in C is poor. Out of the driver source I cannot interpret what's is going on. My assumption is, that at a certain stage, the message is sent in any case without regard if the sending is necessary.

As said, the Simulator seems to be perfect in this case.
Looking forward for any help and lessons to improve my understanding in drivers to be able later on to support writing them.

Michel
2 years 7 months ago #75187

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic Question about driver behavior for CCD Exposures - needed help for understanding.

Hello Michael,

Very good questions. I tested with CCD Simulator with indi_getprop
indi_getprop -m "CCD Simulator".CCD_EXPOSURE.CCD_EXPOSURE_VALUE

Too a 3 second exposure then got this:
indi_getprop -t 0 -m "CCD Simulator".CCD_EXPOSURE.CCD_EXPOSURE_VALUE
CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=1
CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=3
CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=2.3619999885559082031
CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=1.3609999418258666992
CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=0.36000001430511474609
CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=0
CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=0

So I don't see any values over 3.. perhaps this is some Python related issue?

Regarding ASI Camera, it could be that it is retrying capture internally so it doesn't set the state to IPS_ALERT just yet. But you also need to watch out of <message .../> messages, this is where all the reporting is. It is divided to INFO, DEBUG, ERROR, WARN..etc so that your app can easily parses this information and decided which to show to the user and which to perhaps log or ignore.
2 years 7 months ago #75243

Please Log in or Create an account to join the conversation.

  • Posts: 124
  • Thank you received: 28

Replied by Michael on topic Question about driver behavior for CCD Exposures - needed help for understanding.

Jasem,
thanks for feedback and the explanation. I not really with prio one about the first topic, because that does not hurt so far.

I come to the second one as I have the traces of the whole INDI communication present: You're right, the driver also sends some "message" entries (not only for the CCD, but also other drivers). This happens during many (53) exposures only two times, when the exposure time is long (in the case 300s), if the exposure is short (2s) no message is transmitted. The two messages were in INFO state and report end of exposure and end of download.
So still the behavior is in this case strange. What do you think ?
Michel

Edit: I See now the reason for only getting two messages: in the driver I see:

<code>
if (PrimaryCCD.getExposureDuration() > 3)
     LOG_INFO("Exposure done, downloading image...");
</code>
and a second place:
<code>
if (duration > VERBOSE_EXPOSURE)
    LOG_INFO("Download complete.");
</code>
where this limit is treated different.
So why this info is only sent when we have exposures longer than 3s? Why different implementation?
I search for an old thread of us, because this problem hurts the point to find out, when image exposing is finished. Some time ago you helped with the hint:

Regarding the 2nd question, not directly, but you can infer it from CCD_EXPOSURE state:

IPS_IDLE: Idle
IPS_OK: Download completed successfully and camera is now idle.
IPS_BUSY: If CCD_EXPOSURE value = 0, then it is DOWNLOADING, otherwise, it is exposing.
IPS_ALERT: Exposure failed.

and the third state is corrupted with the current implementation of the driver. Does it make sense to expect from the driver when exposure value = 0 the image is fully exposed? From my point yes.
Last edit: 2 years 7 months ago by Michael.
2 years 7 months ago #75263

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic Question about driver behavior for CCD Exposures - needed help for understanding.

Reason for 3 seconds is arbitrary, but goal is now to spam the client with messages for very short exposures. For an image to be considered downloaded, both the state must be IPS_OK and the counter 0. IPS_BUSY with counter = 0, means it is done exposing, but not yet downloaded the image.
2 years 7 months ago #75272

Please Log in or Create an account to join the conversation.

  • Posts: 124
  • Thank you received: 28

Replied by Michael on topic Question about driver behavior for CCD Exposures - needed help for understanding.

Hi Jasem,
thanks for you patience and the explanation. Understood so far.
Back to the ASI driver:
After the while loop, which checks the end of the exposure from the ASI SDK, the driver is sending explicit exposure 0 -> this fits perfect to you explanation, but in the while loop the driver is also sending the exposure time, and this is multiple times send as 0 before we end the while loop. This we should avoid. Does is makes sense to keep the exposure counter on the small value of 0.1 until the while ended? Because then, exposing is explicit finished, as it is taken from the ASI SDK ?
Many thanks.
Michel
2 years 7 months ago #75285

Please Log in or Create an account to join the conversation.

Time to create page: 0.216 seconds