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.
I have not setup ntpd yet. So my system time is not synchronized.
The UTC time in indi client seems to be system time, but not gpsd time.
Is it a bug?
what did you update, kernel or some packages?
petarm wrote: Hi all yep I think wouter had hit it on the head. A few weeks ago I did an update to Ubuntu and all of a sudden usb3 worked.
Another update 4 days ago and usb3 is shot again. Usb2 still works.
Only problem is how does one update anything without breaking something.
The kernel of these ARM boxes are not updated often.
For packages, you can easily find out which ones are related to usdb like libusb
All these research are based on our assumption.
So first we should know the software cause that leads to the dead loop of exposing.
Which ASI APIs are called when the expose time goes to 0 of the dead loop.
Then we can figure out which part of the camera is wrong at the time.
We need the help from dev team.
OK, the similar issue here.
Nano T4 with FirendllyDestop (64bit Ubuntu 18.04). ASI 294 MC Pro
USB2 cable - USB3 port on T4 == Download jam after 7~8 frames
USB2 cable - USB2 port on T4 == OK
USB3 cable - USB3 port on T4 == Download jam after 3~4 frames
USB2 cable - USB2 Hub - USB3 port on T4 == Download jam after 3~4 frames
USB2 cable - USB2 Hub - USB2 port on T4 == Download jam after 3~4 frames, BUT it was OK on once a night!
The USB2 Hub is that on the CEM60, not powered.
I guess the reason is because of power.
USB3 port needs more power and is not very stable with poor AC-IN power.
Multiple USB2 devices will have the same issue above.
Short cable needs less power.
USB2 needs less power.
Connect the guide camera to the USB port on ASI 294 MC Pro instead of the port on Nano T4, because the Hub on ASI 294 MC Pro is powered Hub.