Hi!
I have noticed that a recent update has caused my Ekos to become very confused with optical trains. The multiplier for reducer factor was randomly set to 0, causing my platesolving to fail with an infinite fov error. I could not set the factor to anything besides 0 until I deleted and remade the train, and that train was not editable without inducing the same bug. This is the most recent version that is in the Manjaro repositories (I'll grab exact version # when I get home) Has anyone else experienced this?
I also notice that the scheduler has begun making a very loud, unmutable alarm noise whenever the schedule is stopped. Owchh

Hi,

I installed version 3.6.4 for OSX and when I try to add an optical train ('+' button) Kstars closes without any message.

I tried to delete userdb.sqlite file, but this didn't change anything.

Any advice is welcome.

Ferran

Forget my last message. I needed to delete userdb.sqlite.backup also, and now it works.

github.com/indilib/indi/issues/1899


I touched on the Git problem earlier, but it seems that the newly added optical train affects the connection between the server and the driver.

The driver can be started and connected, but if there is a problem with operation, connect from CCDCiel and it will work normally.

Drivers that can connect to and interact with CCDCiel now work properly. (Use the optical train equivalent connection function implemented on the CCDCiel side instead of Ekos)

Drivers that can't be selected in the optical train, (indiuno-SimpleSwicher in my case), seem to be unable to connect in the control panel even though the driver starts.

Drivers who can't select the optical train are likely to have similar troubles.

Now that optical trains are A Thing, it seems like they'd be useful to put in the FITS header. I think they'd also be useful as a filename placeholder, so that if you have different trains you don't end up scribbling a bunch of differently composed images under Pictures/M27/Light/LXtreme ... and only later do you realize that some of those were taken at one focal length and some were taken at another. Totally didn't happen to me... (whistles innocently)

Putting the mount type in the header as the TELESCOP doesn't make much sense to me, since it's not the thing focusing the electromagnetic radiation on to the detector. If you went from a 60mm refractor on an HEQ-5 to a 120mm refractor on the same HEQ-5 I think you'd expect to see that somewhere in the FITS header.

I'm scribbling together some python scripts to sort and fix these things, but I thought I'd mention it here too.

The focal length always appears in my FITS headers. Of course, if we change focal lengths while keeping the same mount, it's up to us to make the change in the train specifications. Another option is to have a unique Ekos name for each focal length that uses the same mount.

This obviously doesn't solve the file name problem. However, if you have a bunch of files and you're not sure of the FL for each one,
grep -l 1.55 *.fits > 155files
will put the name of every FITS file that has 155 as its focal length into a file named 155files. Note that the internal FL storage in a FITS file is in exponential format, e.g., 1.55E+02

Rendering Error in layout Message/Item: array_keys(): Argument #1 ($array) must be of type array, null given. Please enable debug mode for more information.

Please Log in or Create an account to join the conversation.