Okay, do you know who that is/how I can contact them?

Read More...

Thanks for the reply. The INDI server and the client are running in separate docker containers linked with a docker network, and yes, the INDI server continues to run after the client is forcibly disconnected. If the docker container with the client is rebooted, it will connect to the INDI server again with no problems. However, the fact that it disconnects after an exposure is a pretty large issue in the context of the project I’m working on, because there is nothing in the client that tells the server to disconnect after an exposure. Also, I have only use PyIndi so I am not very familiar with the C++ client, but I would also assume it works along the same lines. Do you know what the error code -1 signifies?

Read More...

I should have added, this is my newBLOB method for post-exposure image processing:

def newBLOB(self, bp):
        self.logger.info("new BLOB " + bp.name)
        print("name: ", bp.name," size: ", bp.size," format: ", bp.format)
        # get image data
        fits=bp.getblobdata()
        print(type(fits))
        # write image data to BytesIO buffer
        blobfile = io.BytesIO(fits)
        # open a file and save buffer to disk
        with open("%s.fits" % datetime.now(), "wb") as f:
            f.write(blobfile.getvalue())
        blobfile.close()


Read More...

Hello. I'm writing a client using PyIndi-Client to control a ZWO ASI6200MM Pro. I am using Python package Flask to allow for the exposure info to be sent as a http POST request. The client and indiserver are running on a Raspberry Pi 4. The camera is not attached to any telescope but is connected to the RPi4 via USB. When I send the POST request to take the exposure, the client outputs the following:

2020-07-24 20:46:29,834 new Message 2020-07-24T20:46:29: [INFO] Taking a 10 seconds frame... 
2020-07-24 20:46:29,836 172.19.0.1:59174 POST /elements/1/cameras/1:startExposure 1.1 202 57 9393
[2020-07-24 20:46:29,836] 172.19.0.1:59174 POST /elements/1/cameras/1:startExposure 1.1 202 57 9393
2020-07-24 20:46:40,939 new Message 2020-07-24T20:46:40: [INFO] Exposure done, downloading image... 
2020-07-24 20:46:41,064 new Message 2020-07-24T20:46:41: [INFO] Download complete. 
2020-07-24 20:46:41,066 new Message 2020-07-24T20:46:41: [WARNING] Telescope focal length is missing. 
2020-07-24 20:46:41,067 new Message 2020-07-24T20:46:41: [WARNING] Telescope aperture is missing. 
INDI server indiserver/7624 disconnected.
2020-07-24 20:46:43,274 Server disconnected (exit code = -1,indiserver:7624)

In case it is relevant to know, here is the simple script to send the request:
import requests

url = 'http://localhost:9001/elements/1/cameras:startExposure'
data = {'exposure':10}

x = requests.post(url, json = data)

print(x.text)

I have copied code from www.indilib.org/develop/indi-python-bindings.html to print out BLOB information after the exposure is taken, but this is obviously not printed before the indiserver disconnects, so it seems the problem happens after the exposure is taken but before the indiserver receives the BLOB. I am hoping someone can explain what the error code -1 means (I have been unable to find any documentation of indiserver error codes) and tell me if there is some way to fix this problem. Thank you.

Read More...

Hello. I'm attempting to build a docker container that when run will build the indi library from PPA and start an indiserver with indi_asi_ccd used for a ZWO CCD ASI6200MM Pro. Here are the contents of the dockerfile:

FROM ubuntu:18.04

WORKDIR /indiserver

RUN apt-get update && \
    apt install -y software-properties-common && \
    apt-add-repository ppa:mutlaqja/ppa && \
    apt-get update -y && \
    apt-get install -y indi-full gsc
    
RUN mkdir -p /indiserver

COPY . .

CMD ["indiserver", "indi_asi_ccd"]

The docker container is built with
docker build -t indiserver .
and run with
docker run -it indiserver

Here is the console output when the docker container is run:
$ docker run -it indiserver
2020-06-30T18:30:16: startup: indiserver indi_asi_ccd 
^C2020-06-30T18:30:18: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
Child process 8 died
2020-06-30T18:30:18: Driver indi_asi_ccd: restart #1
^C2020-06-30T18:30:19: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"Child process 11 died
/>
2020-06-30T18:30:19: Driver indi_asi_ccd: restart #2
^CChild process 14 died
2020-06-30T18:30:20: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
2020-06-30T18:30:20: Driver indi_asi_ccd: restart #3
^C2020-06-30T18:30:21: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
Child process 17 died
2020-06-30T18:30:21: Driver indi_asi_ccd: restart #4
^C2020-06-30T18:30:21: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
Child process 20 died
2020-06-30T18:30:21: Driver indi_asi_ccd: restart #5
^C2020-06-30T18:30:21: Driver indi_asi_ccd: stderr EOF
<delPropertyChild process 23 died
 device="ZWO CCD ASI6200MM Pro"/>
2020-06-30T18:30:21: Driver indi_asi_ccd: restart #6
^C2020-06-30T18:30:22: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
Child process 26 died
2020-06-30T18:30:22: Driver indi_asi_ccd: restart #7
^C2020-06-30T18:30:22: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"Child process 29 died
/>
2020-06-30T18:30:22: Driver indi_asi_ccd: restart #8
^C2020-06-30T18:30:22: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
Child process 32 died
2020-06-30T18:30:22: Driver indi_asi_ccd: restart #9
^C2020-06-30T18:30:22: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
Child process 35 died
2020-06-30T18:30:22: Driver indi_asi_ccd: restart #10
^C2020-06-30T18:30:22: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI6200MM Pro"/>
Child process 38 died
2020-06-30T18:30:22: Driver indi_asi_ccd: Terminated after #10 restarts.
2020-06-30T18:30:22: good bye

Could anyone help me fix this error? Thanks.

Read More...

Stephen Berg replied to the topic 'Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

Well Jasem, I finally got everything working. It turns out in my script the list of properties was being printed out before the connection to the indiserver was established - a simple mistake on my part. I added some time.sleep calls to wait before printing the properties, and lo and behold, the CAP_PARK property is there. The updated driver works perfectly when changing the CAP_PARK switch as well.

I'm sure I was a real nuisance to deal with, so I apologize. I really do appreciate all of your help though! Thanks for everything!

Read More...

Stephen Berg replied to the topic 'Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

The dust cover is, and has been, connected via usb to the raspberry pi this whole time. Did you really think we wouldn’t connect the device we are trying to control?

Read More...

Stephen Berg replied to the topic 'Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

Hello again Jasem,

I did git pull from the indi repo and tested by running $ indiserver indi_flipflat

This time around, the output from my flask app shows this:
List of Device Properties:
--Flip Flat
> CONNECTION
SWITCH:CONNECT(Connect)= Off
SWITCH:DISCONNECT(Disconnect)= On
> DRIVER_INFO
TEXT:DRIVER_NAME(Name)= Flip Flat
TEXT:DRIVER_EXEC(Exec)= indi_flipflat
TEXT:DRIVER_VERSION(Version)= 1.0
TEXT:DRIVER_INTERFACE(Interface)= 33792
> DEBUG
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> SIMULATION
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> CONFIG_PROCESS
SWITCH:CONFIG_LOAD(Load)= Off
SWITCH:CONFIG_SAVE(Save)= Off
SWITCH:CONFIG_DEFAULT(Default)= Off
SWITCH:CONFIG_PURGE(Purge)= Off
> POLLING_PERIOD
NUMBER:PERIOD_MS(Period (ms))= 1000.0
> CONNECTION_MODE
SWITCH:CONNECTION_SERIAL(Serial)= On
> DEVICE_PORT
TEXT:PORT(Port)= /dev/ttyUSB0
> DEVICE_BAUD_RATE
SWITCH:9600(9600)= On
SWITCH:19200(19200)= Off
SWITCH:38400(38400)= Off
SWITCH:57600(57600)= Off
SWITCH:115200(115200)= Off
SWITCH:230400(230400)= Off
> DEVICE_AUTO_SEARCH
SWITCH:INDI_ENABLED(Enabled)= On
SWITCH:INDI_DISABLED(Disabled)= Off
> DEVICE_PORT_SCAN
SWITCH:Scan Ports(Scan Ports)= Off
> SYSTEM_PORTS
SWITCH:/dev/ttyUSB0(/dev/ttyUSB0)= Off
> ACTIVE_DEVICES
TEXT:ACTIVE_FILTER(Filter)= Filter Simulator

Note that the flat light property from before is not shown, which stands to reason, but there are no properties relating to the dust cap itself.

Read More...

Stephen Berg replied to the topic 'Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

Hey Jasem, finally got it to work. The command returned *P98

Read More...

Stephen Berg replied to the topic 'Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

Hey Jasem,

So I have been trying to get the product ID with the >P000 command you mentioned earlier. I have been looking for references to the >P000 command, and how to use it, but I haven't found any documentation anywhere. It's easy to enable verbose logging when I run the indiserver (using -vvv) but when it's running there doesn't seem to be a way to issue commands to it from the command line. Again, we aren't using Ekos due to the nature of our client. We have not tried to use minicom so that may be why we are still stuck. Using minicom also seems strange to me because it is used as a serial port communications program but our devices are connected by serial bus, not serial ports. Our dust cover is connected by USB to the CCD we are using, which in turn is connected by USB to the raspberry pi where our client and indiserver are running. Would either of those details make a difference when using minicom? Thanks.

Read More...

Stephen Berg replied to the topic 'Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

I'm sorry, I'm still fairly new to linux, and I'm still in the process of learning to use it proficiently (have to start somewhere). Your previous reply is confusing to me. Isn't the Product ID just the second part of the pair of values returned by lsusb? So the PID of our dust cover would be 6003 if that's the case. I've also never used minicom before (I actually never heard of it until you mentioned it in your comment) so I'll have to learn to use it before replying with the product ID. Again, sorry that I'm such a novice.

Read More...

Stephen Berg replied to the topic 'Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

The VID:PID of our dust cover is 0403:6001, obtained by using lsusb.

Read More...

Stephen Berg created a new topic ' Requesting help with Alnitak Remote Dust Cover device properties' in the forum. 2 months ago

Hello,

I'm a college student working with a professor to build a client using Python packages PyIndi-client and Flask that will be capable of controlling hardware mounted to a telescope through http requests. The telescope will be receiving sequences of http requests to automatically take observations through the whole night, so we are not going to be using Kstars or Ekos, or any other GUI. Our hardware is currently plugged in via USB to a raspberry pi 4, on which the client and indiserver are running.

The dust cover he chose to use is the Alnitak Remote Dust Cover, seen here: www.optecinc.com/astronomy/catalog/alnit...emote_dust_cover.htm
The alnitak driver I got from this page: indilib.org/devices/auxiliary/alnitak-flip-flat-flat-man.html , which says to start the indiserver with the driver indi_flipflat.

In the client, one of my methods for testing prints out all the connected device properties. The problem I am having is that the dust cover does not seem to have a property that controls whether the dust cover is open or not. It actually provides a property to control the flat light, which our dust cover doesn't have. Here is the printout:

(test) ubuntu@pi-1:~/client_test$ flask run
Connecting and waiting 1 sec
List of connected devices:
Flip Flat
List of Device Properties:
--Flip Flat
> CONNECTION
SWITCH:CONNECT(Connect)= On
SWITCH:DISCONNECT(Disconnect)= Off
> DRIVER_INFO
TEXT:DRIVER_NAME(Name)= Flip Flat
TEXT:DRIVER_EXEC(Exec)= indi_flipflat
TEXT:DRIVER_VERSION(Version)= 1.0
TEXT:DRIVER_INTERFACE(Interface)= 33792
> DEBUG
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> SIMULATION
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> CONFIG_PROCESS
SWITCH:CONFIG_LOAD(Load)= Off
SWITCH:CONFIG_SAVE(Save)= Off
SWITCH:CONFIG_DEFAULT(Default)= Off
SWITCH:CONFIG_PURGE(Purge)= Off
> POLLING_PERIOD
NUMBER:PERIOD_MS(Period (ms))= 1000.0
> CONNECTION_MODE
SWITCH:CONNECTION_SERIAL(Serial)= On
> DEVICE_PORT
TEXT:PORT(Port)= /dev/ttyUSB0
> DEVICE_BAUD_RATE
SWITCH:9600(9600)= On
SWITCH:19200(19200)= Off
SWITCH:38400(38400)= Off
SWITCH:57600(57600)= Off
SWITCH:115200(115200)= Off
SWITCH:230400(230400)= Off
> DEVICE_AUTO_SEARCH
SWITCH:INDI_ENABLED(Enabled)= On
SWITCH:INDI_DISABLED(Disabled)= Off
> DEVICE_PORT_SCAN
SWITCH:Scan Ports(Scan Ports)= Off
> SYSTEM_PORTS
SWITCH:/dev/ttyUSB0(/dev/ttyUSB0)= Off
> ACTIVE_DEVICES
TEXT:ACTIVE_FILTER(Filter)= Filter Simulator
> FLAT_LIGHT_CONTROL
SWITCH:FLAT_LIGHT_ON(On)= Off
SWITCH:FLAT_LIGHT_OFF(Off)= Off
> FLAT_LIGHT_INTENSITY
NUMBER:FLAT_LIGHT_INTENSITY_VALUE(Value)= 0.0
> Status
TEXT:Cover(Cover)= Not Open/Closed
TEXT:Light(Light)= Off
TEXT:Motor(Motor)= Stopped
> Firmware
TEXT:Version(Version)= 200
Flip Flat: CONNECTION property defined
* Serving Flask app "condor-flask-client"

See? Nothing about the actual dust cover.

Out of curiosity, I wrote a method to change the status of the non-existent flat light. Strangely enough, the dust cover reported back a success, although nothing changed about the dust cover in real life.

So there's my dilemma. What am I doing wrong? I would really appreciate if anyone could shed some light on this.

Read More...