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

Read More...

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

Read More...

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

Read More...

Hi Jasem,
I recognized wrong measurements in Pegasus UPBv2 currents (main, single line and dew). I compared the driver to the actual specification (02. Feb 21) and saw wrong coefficients. I corrected them in the driver and made a pull request. Please review.

pegasusastro.com/wp-content/uploads/2021...al_Command_Table.pdf

Michel

Read More...

Michael replied to the topic 'QHY600 1x1 binning mode' in the forum. 2 months ago

Jasem,
many thanks !
Michel

Read More...

Michael replied to the topic 'QHY600 1x1 binning mode' in the forum. 2 months ago

Hi Jassen,
many thanks for the hint. Could you agree if this setting is wrong, the server might cut the transmission ?
Secondly: When I look to indiweb it already calls with 1000, so there must be 1000 * 1024 * 1024 received memory 

cmd = 'indiserver -p %d -m 1000 -v -f %s > /tmp/indiserver.log 2>&1 &' % 
but I still get the log
2021-08-08T09:45:30: Client 25: 105.842.564 bytes behind, shutting down
How could this happen ?
Thanks for your support.
Michel

Read More...

Michael replied to the topic 'QHY600 1x1 binning mode' in the forum. 2 months ago

Hi,
from my point of view the indiserver causes the problem due to the fact that QHY600 needs for it's images more memory. Out of the indidserver.log from my mount located pc I got the entry:

2021-08-08T09:45:30: Client 25: 105842564 bytes behind, shutting down

as this limit is coded in indiserver.c which is 128Mbyte 
The camera itself has with bin 1x1: 9600x6422 = 61651200 pixel including overscan etc. and the pixel are 16 bit. This makes 123302400 Bytes, so very close. If you take into account that you need to encode this binary values base64, the size expands about 30%. So if the image transfer starts at a point, when the image is fully received from the driver itself, the server is always more than this buffer size behind and shuts down.
If you are accessing the data without passing the server -> you are around this possible bottleneck.

@jasem: it would be nice if you could check this theory 
Michel

Read More...

So it's like the tries before: I edited the first entry (opening port for the thread) and there it is marked as solved. But this does not propagate through to thread title. What I am missing?
Im on MacOS, using safari.
Michel

Read More...

Michael replied to the topic 'How to mark thread title as solved' in the forum. 2 months ago

Hi, many thanks for the hint.
That was the way I tried it. For some reasons it did not work. Actual try everything is OK. So It worked still not knowing what I did wrong the first time.
Anyway I now know how to do it.
Michel

Read More...

Michael created a new topic ' How to mark thread title as solved' in the forum. 2 months ago

Any help, I searched, but did not find anything.
Michel

Read More...

Michael replied to the topic 'USB Download problem QHY600' in the forum. 2 months ago

As stated im my mail: with the last SDK the problems were solved. Many thanks !
Michel

Read More...

Hi Kurt,
I also tried to install ubuntu 21.04 and did succeed as the were packages held back fir Indi. Moving back to 20.04.2 LTS fixed the problem.
Michel

Read More...

Michael replied to the topic 'USB Download problem QHY600' in the forum. 3 months ago

Hi Jasem,
thanks for the quick reply. I raised an issue to QHY, but so far not response.
I also changed the memory value up to 2048 in 85_qhyccd.rules to that the memory (confirmed) is 2048.
Still once I start download I see in journalctl -fJul 15 20:29:03 astro-comp kernel: usb 4-1: reset SuperSpeed Gen 1 USB device number 9 using xhci_hcdJul 15 20:29:03 astro-comp kernel: usb 4-1: LPM exit latency is zeroed, disabling LPM.Any idea ?
Michel

Read More...