Since 1.8.2 indi-full has changed its structure of 3rd party drivers. All the package have new names.
While oacapture is dependent on old packages like libasicamera and libefwfilter which are replaced by new packages in indi1.8.2.
So this cause the conflict.
The oacapture deb can be installed with 'dpkg -i --ignore-depends=libasicamera,libefwfilter', and does work good.
I have mail to the author of oacapture, james, but no response by now.
This is a reminder for the people who want to install oacapture on you system.
To solve the conflict, you need to uninstall all the oacapture packages before you upgrade indi to the latest build. Install oacapture again with the ignore option
And also, you need to modify a file to change the oacapture dependency.
Find oacapture and remove libasicamera and libefwfilter in the line 'Depends'.
What I want is the data in the Ekos status page. Some of them are not read from indi.
Kaczorek wrote: Interesting idea!
There's nothing that works out of the box but you can use some bash scripts with indi_getprop or develop python app using pypi.org/project/pyindi-client/
For example, the CCDCiel status web page is a source that I can decode the html code and filter out the useful data.
I'm trying to collect some data from the running Ekos and send them through bluetooth to WatchX - A programable arduino watch.
I want to get job status/progress, guiding rms, RA/DEC, etc.
So is there any interface that I can get these data from Ekos?
There is an issue with GPS dongle together with chrony/ntpd.
I wonder whether you have met such issue
I do but not on C++
I'm not sure whether I could handle it or not.
The modern newton style telescope uses off-axis secondary mirror which could make the unfocused spot (a tiny ellipse) show the minimum HFR.
So the HFR could not represent the correct focus spot.
In my F4 Mak-Newt, the minimum HFR spot is always a vertical ellipse. I need to move the focuser a little out to get a proper round disk. This correction will only increase 0.1-0.2 HFR.
So I suggest to add roundness as for the Y value of the curve so that we can change monitoring from HFR to roundness when we like.
So the focus progress would be like that:
move focuser in one direction based on the HFR when HFR > 1.5 (a parameter)
received first <1.5 HFR
change Y value to roundness, calculate roundness instead of HFR
move focuser in the same direction and record roundness
received maximum roundness
move focuser back to meet the maximum roundness
I hope such function to be added into the focus module as an option.
Should this be performed before or after a mount synchronization ?
As @IHOUJIN described, it very easy to get the GPS time. So why the indi_gpsd does not get it?
To run the ntpd/chrony will cause a problem under indi.
The gpsd is default to run as plug&play mode, that mean it will scan all the serial ports (ttyUSB0 and other ttyXXX). And to setup chrony to sync datetime needs "-n" option of gpsd, which makes gpsd to lock all the serial ports all the time.
So the mount model will report "the device is used by other program" on /dev/ttyUSB0
To fix it we need to change the plug&play off (USBAUTO=false) and input the device name for gpsd, /dev/ttyACM0 for example.
This is so boring.
People need to write a script / or to change many settings to make the gps work for indi. Is it the true design of this function?
Why not get and update the datetime by inde_gpsd?
USB3 port -> USB2.0 cable -> CEM60 Hub -> USB2.0 Cable -> ASI290 mini
USB2 port1 -> PL2302 USB to COM -> CEM60 com
USB2 port2 -> USB3.0 cable -> ASI290MC Pro
Capture 200S X 12, -12C, with guiding on, works good.
So I can give the result that:
Only true USB 3.0 connection will cause problem.
The USB2.0 cable will not lead to USB3.0 driver working, even on the USB3.0 port.
The MC Pro camera with non-power USB hub will cause problem.
The problem is complexity, it may be some memory leak of the USB3.0 driver, and also the MC Pro camera is sensitive to the USB power.
Hi, this is not about 'How to get datetime from gpsd'.
This is to concern which time should be displayed on the panel of indi_gpsd.
Does this work as design or be a bug?
And which time will kstars use?
The system time is shown on the panel will make confusion.