When using indi in phd2, there is an option to control the use of streaming ( force it, prevent it). Worth a try in your case.

Read More...

Hi Denis

We certainly miss that documentation !

The fast-blob protocol is mostly the same than default one, with the following deviations:

• The client must connect to unix domain socket (only supported under Linux, MacOS lacks some important feature there...).
• the client has to reply to "pingRequest" messages by "pingReply" (this implements the back-pressure, see below why it's important). The uid attribute from the request must be repeated in the reply:

  <pingRequest uid='2'/>
  <pingReply uid='2'/>

• on UNIX domain connection, the server can pass the blob content as an anciliary file descriptor (man7.org/linux/man-pages/man7/unix.7.html). The file descriptor can later be mmapped. In that case, the xml message will have the attached property set to true (and no enclen by the way):

  <setBLOBVector device='fakedev1' name='someblob' timestamp='2018-01-01T00:01:00'>
      <oneBLOB name='content' size='32' format='.fits' attached='true'/>
  </setBLOBVector>

Remark 1: It is guaranteed that the file descriptor(s) for attached blob(s) are received by the end of the xml message. The exact position probably depends on the OS.
Remark 2: The server may also decide to not used shared buffer so the client must still support the use existing base64 layout (for example for small blobs)
Remark 3: The transport of buffers as filedescriptor can be very very fast, so your client may receive GB of data without much processing. Without backpressure, memory in the client side may grow uncontrolled (ultimately leading to Out of memory error, possibly system wide invoking the OOM killer). For this reason, it is strongly advised that when a blob arrive, the client stops processing incoming messages (especially replying to pingRequests) until it has finished processing the blob.
Remark 4: To actually free the memory used by a filedescriptor, the client must close the fd, and munmap the memory area.

Some example of low level functions for these tasks can be found in the indi source file integs/test.cpp (integration tests), which is somewhat decoupled from indi so probably easier to read for a start:

• integs/test.cpp: the unixSocketConnect function - to connect to a local socket by path name
• integs/ConnectionMock.cpp, method ConnectionMock::read, shows how to read the input channel, collecting received fds at the same time
• integs/SharedBuffer.cpp, shows how to access memory from a fd. It is in the write direction, while you client will want to read insted. So your client should use PROT_READ only and remove PROT_WRITE)

Tests codes in the integs directory may also be useful as they show the plain text version of the messages for various cases.

Hope this helps!

Read More...

This is transparent as long as:
* server and client run on the same host
* server is recent enough
* client also uses updated library
* client connects specifically to localhost (especially not 127.0.0.1). You can also force it with "localhost:/tmp/tmp/indiserver". This will refuse to connect if using a log library

You can check in the indiserver log: when a client connect with the new scheme it display a message about local domain:

... new arrival from local ...

Versus plain old tcp connection which display :

...new arrival from <ip-address>:port

Read More...

Hi

This part of your log file indicates you need to recompile your driver against the latest indi lib:


indi_qhy_ccd: undefined symbol: _ZN4INDI3CCD15addFITSKeywordsEP8fitsfilePNS_7CCDChipE"

Read More...

Hello, I mean from the connect dialog, in the INDI settings. (see the screenshot...)

Read More...

You can try not using streaming on phd2 settings, it works differently and may not be affected by the problem...

Read More...

Hi !

I can confirm the asi driver will generate these reset messages in kernel logs, probably for every exposure, and that is totally armless. So it's probably not the cause or a symptom of your problem !
You should try without any hub...

Read More...

A bit of topic, but you could probably detect focuser slips using a usb microscope. It gives enough resolution for 10 micron moves, probably lower, for 20$.
I would bet your setup already includes a raspberry pi to automate that

Read More...

This comes from zwo sdk that imposes capture size being a multiple of 8, which is not the case for the binned full frame.
For phd2, this problem has been solved in latest builds: It now accomodates to the resolution change when using dark lib

Read More...