Khalid replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 1 month ago

James / Alain,

Version 3.x of OnStep (which is 'master' in Github), has a new way for configuration which is much easier than before. Instead of one Config file for each board, there is a unified Config.h file.

It also has support for a persistent command channel on port 9998, which can make OnStep work over WiFi. Previously, port 9999 does not work because it times out after 2 seconds and closes the connection. The new port needs to be tested.

Another change is in how the focuser works, with new commands. Details in this message .

Read More...

Khalid replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 1 month ago

The master branch of OnStep (version 3.0h) now has support for communicating with it over WiFi.

If your controller has a WiFi module, you need to re-flash that module with the WiFi-Bluetooth addon from the above version.

The difference is that you use port 9998, but keep using 9999 for the Android App as usual.
For INDI, you can change that under the Connect tab.

This was tested with Stellarium Mobile Plus and found to be working.

More detail here .

Read More...

Khalid replied to the topic 'TeenAstro driver for INDI - communication errors' in the forum. 1 month ago

I posted a description of a possible solution here .
Someone needs to implement and test it.

Read More...

Khalid replied to the topic 'TeenAstro driver for INDI - communication errors' in the forum. 1 month ago

I don't have a solution.
But if I am not mistaken, James Lancaster, a maintainer of OnStep INDI was looking into it a couple of months ago.
No word so far.

By the way, this file has the code that handles WiFi for OnStep (TeenAstro would be similar), and there is 2000L on line 394. Also see line 388.

Read More...

Khalid replied to the topic 'TeenAstro driver for INDI - communication errors' in the forum. 1 month ago

fdesvallees wrote: I found out the problem was in the board which would close the connection after 2 seconds.


TeenAstro is based on OnStep. What I am going to say applies to OnStep, and probably to TeenAstro as well.

OnStep does not keep the TCP connection open for subsequent communications. As a result, each command has to establish communication as if it is a new connection.

I wrote a Python API for OnStep , and I had to connect on every call, when using TCP.

Read More...

Khalid replied to the topic 'EOS 6D unstable after latest update?' in the forum. 2 months ago

What I found is that if I start an exposure with the QHY, it never ends (no image download), and after that the Canon 650D/T4i also never downloads. If I delete the QHY from the profile, and therefore no exposures through it, the Canon works fine.

Read More...

Khalid replied to the topic 'EOS 6D unstable after latest update?' in the forum. 2 months ago

terryfitz wrote: Personally, I'm convinced it's a problem with the QHY driver since, though I can't get KStars to run reliably on the rPi4, I did get the INDI server running and got PHD2 open with the QHY5LIIM camera, but it refused to download and preview any images. If I had al alternative guide camera to the QHY, I would try that to see if it made any difference, but I don't sadly.


I have the exact symptom.
After upgrading to the latest QHY, it stopped working.
The exposure counts down, then no image is downloaded.

Is there any way to go back to an earlier INDI-QHY driver (and maybe an earlier CANON one) since this has all just apparently started with the September release - it may just be coincidence, but again, this would be a way of eliminating things that aren't the cause of the problem.


The Canon driver works, at least for my 650D/T4i.

Read More...

Khalid replied to the topic 'QHY 5r-IIC Ekos Strange Behaviour' in the forum. 2 months ago

I am seeing a similar problem, but with the QHY5-II-M

When running qhy_ccd_test, I see this repeating forever ...

QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame begin
QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame ret=-1 chipoutputsizex * chipoutputsizey * cambits / 8=1228800

And Ekos does not download an image from the QHY.

Read More...

Khalid replied to the topic 'QHY driver died after trying to install v1.8.1' in the forum. 2 months ago

The reinstall was like this:

sudo apt-get purge indi-bin indi-qhy
sudo apt-get install indi-bin indi-qhy indi-gphoto kstars-bleeding

Read More...

Khalid replied to the topic 'QHY driver died after trying to install v1.8.1' in the forum. 2 months ago

I have the same problem.
The QHY driver does not work. I am not sure if this is the fault of the latest version from Jasem's PPA or something else.
So, I tried to uninstall and reinstall everything, but things are worse: now the Canon driver does not work.

Even running gphoto from the command line does not work:

env LANG=C gphoto2 --filename m13.jpg --wait-event=1s --set-config eosremoterelease=5 --wait-event=20s --set-config eosremoterelease=11 --wait-event-and-download=5s

The result are these messages:

Waiting for 1 seconds for events from camera. Press Ctrl-C to abort.
*** Error ***
PTP Timeout
*** Error ***
An error occurred in the io-library ('Timeout reading from or writing to the port'): No error description available
*** Error ***
PTP Timeout
*** Error ***
An error occurred in the io-library ('Timeout reading from or writing to the port'): No error description available

And no image ever completes ...

Read More...

Khalid replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 months ago

It is a known issue, and has to do with the timeout.
For an unrelated, but similar API, I had to issue a connect before sending every command.

James Lancaster is working on it, and his latest status update is here

onstep.groups.io/g/main/message/12653

Read More...

Khalid replied to the topic 'Ekos autoguiding troubles' in the forum. 3 months ago

knro wrote: So the recommended proportional gain for a 0.5x guide rate is 133x which is the default. What's the guide rate for your mount?


It is set to 0.5X.

I can indeed see that the mount reacts strongly to the guiding pulses, but I think a big factor here is the time between exposures. 7 seconds is too long when guiding. Ideally, it should be between 1-4 seconds (counting download time as well).


That is odd.
I never set it that high. I think it was 4 seconds.
Maybe the download doubles it.

I will lower it to 2 seconds then next time I am out.

The minimum pulse should be <strong>increased</strong>, not decreased. So if the guider decided it needs to pulse for 150ms, but the minimum pulse is set to 200ms, then the 150ms pulse is completely discarded. Think of it as a "dead-zone", any pulses below the minimum and above the maximum are <em>ignored</em>


So it is better to set the pulse range to very low and very high (say 20 and 5000)?
That way, no discarded instances?

Read More...