fusis wrote: Just to add, I use same binning, etc.
And what's more, the flats and darks do not give me: ** Warning: The FITS format does not define an unambiguous orientation of pixel data. The coordinates read on the image may be wrong.
So it's just the lights that seem to contain the unambiguous orientation data.
Possibly the darks and flats do not have coordinates data in them. You can check this by inspecting the fits header.
Can you share a few of each via dropbox, google drive, or similar?
fusis wrote: The Calibration frames were also taken in ekos. Flats and darks.
Same binning? No subframe?
This may be helpful:
Regarding the geometry error - frames pulled via indi w/ Ekos and other clients (PixInsight included) are definitely different than those captured with TheSkyX on Linux (incl RPi) for at least the FLI drivers. As an example I get overscan margins w/ indi but not with TSX. It's probable that other cameras are similar. I wouldn't be surprised if this is the case.
PixInsight will error if the image geometry (matrix size, possibly pixel depth too) is not exactly the same between the calibrating frame and the frame to be calibrated - they can't line up.
I think the fits warning is normal. Pixinsight tries to push you to use the xisf file format over fits for the reason described in the error you got.
If you are trying to calibrate with Cal frames captured with a different tool than ekos the incompatible geometry error can happen. This has to do with how different drivers read out the camera. Try grabbing some Cal frames within ekos.
Yep - that got it done. Thanks! I see astrometry.cfg defaulted to a homebrew location for the indices, which I did not have installed. I created the folder similar to your example and all is well.
Before getting the Astrometry part done I did some very basic imaging which amounted to mainly camera control using a Sony A7S via the indi Gphoto driver. Things pretty much just worked. I did notice that live view did not work. I seem to recall it working in the past but its been almost a year since I used that feature so the details of what might have been different escape me.
Anyway, hopefully the report helps and thanks for the fast feedback and effort on the whole thing!
These are my notes of a fresh install of 3.0 on a 2016 MBP running 10.14 (Mojave). By fresh I mean I removed the prior semi-operable 2.9 version of kstars per the quickstart doc in the dmg, including all config files and directories.
- Starts up, give 1st time config dialog.
- Copy kstars directory to Application Support. Main window launches.
- Start GSC download, begins progressing.... didn't wait for it to finish
- Clicked Next, set location to my location. Clicked OK - CRASH (see attached output)
- restart - error "Unable to find INDI Drivers directory: /usr/local/share/indi. Please make sure to set the correct path in KStars configuration". Application otherwise starts and 1st time config dialog re-appears
- Get to location selection, click OK - CRASH.
- Restart, skip GSC download, set location - worked.
- Go into Ekos, attempt to configure indi devices - none available (presumably no drivers)
- Find the drivers located at /Applications/kstars.app/Contents/MacOS/indi
- Go into Preferences->INDI to set this. As soon as I check the box to the left of the path the path changes to **Internal INDI Server**
- XML directory is blank - on clicking the box to the left of it it changes to **Internal INDI Drivers**
- Astrometry gives a missing or corrupt error, showing the location to be /usr/local/etc/astrometry.cfg. Confirmed this does not exist.
- Found astrometry.cfg in /Applications/kstars.app/Contents/MacOS/astrometry/bin, but I can't seem to set this in Ekos. I also can't reset to defaults - it's greyed out.
I never got GSC to download, not sure how to get it to do that once things are set up.
I reproduced the kstars/ekos freeze with the simulators yesterday. To do this I copied the "bad" kstarsrc file back into place, started kstars, and launced Ekos w/ the default simulators. After using Ekos for a few minutes the entire application would freeze up similarly to how it does with the normal set of equipment running. It doesn't seem to happen as quickly though, not sure why.
Reverting back to a "new" kstarsrc I testing the addition of a "throw away" job last night, I ran into a similar situation that was at the start of this thread. I managed to get the window logs but not the debug logs as the log setting must be stored in kstarsrc and logging was off. The first job completed successfully, the second job started and slewed, focused, aligned, and appears to have started guiding when it seems like the software went to sleep or something. This is the log entry for the scheduler:
2018-11-08T04:48:06 Job 'prj_Mel15a' is aborted. 2018-11-08T04:48:06 Job 'prj_Mel15a' is now approaching astronomical twilight rise limit at Thu Nov 8 04:48:00 2018 (30 minutes safety margin), marking aborted. 2018-11-08T00:51:53 Job 'prj_Mel15a' capture is in progress... 2018-11-08T00:51:53 Job 'prj_Mel15a' guiding is in progress.
This is what I saw in the imaging module. Seems to have hung waiting for the filter to move. Checking the wheel, it was on SII:
2018-11-08T00:51:53 Changing filter to SII... 2018-11-08T00:51:53 Job requires 3,600.000-second SII images, has 0/3 frames captured and will be processed. 2018-11-08T00:51:53 Ekos will refocus in 4304 seconds, last procedure was 196 seconds ago. 2018-11-08T00:51:53 CCD capture aborted 2018-11-08T00:51:53 Autoguiding stopped. Aborting... 2018-11-08T00:51:51 Changing filter to SII... 2018-11-08T00:51:51 Job requires 3,600.000-second SII images, has 0/3 frames captured and will be processed. 2018-11-08T00:51:51 Ekos will refocus in 4306 seconds, last procedure was 194 seconds ago. 2018-11-08T00:48:37 Ekos will refocus in 4500 seconds.
I've attached the full Ekos window log.
I was able to reproduce the hang with the sims previously. I found that deleting ~/.config/kstarsrc seemed to get things going again. Thinking ahead, I simply renamed it last time so I still have a copy. I'll give it a test and see how reproducible it is with the sims. It was 100% reproducible with the actual hardware.
Update - the problem came back last night. The system seems to have hung mid job and only captured one image. On re-launching kstars things seemed fine. On starting Ekos, again things were fine. On starting indi, after a short period the whole thing froze up. I repeated this several times.
After a bit of short testing I found that removing the file ~/.config/kstarsrc allowed things to operate again. Testing another run tonight.
I added a third job to capture a single sub of M42. I forced it to be the last job by setting the priority. After a few mishaps, I started the job and let it go. I came back to find it had started the first sub, then went to bed. One of the mishaps was odd - after guiding started, the capture module hung up on "changing filter" for about 15 minutes. I confirmed the filter wheel was operating and was on the correct filter. All seemed in order there but Ekos just stopped for no reason I could see.
I woke this morning, powered things down from my phone (different interface for the power controls) and went about getting ready for work. A checked the folder where the subs were to go and found only 1 sub, not the 6 1h subs I expected. What really got me is that that sub had a timestamp equal to the time when I powered everything down. Also, I have an external (to Ekos) automation that does last-resort parking of the mount. It runs at sunrise. Ekos did not notice the mount had parked.
Baffled, I logged in and looked at Ekos which was still running. I see the jobs aborted, etc in the status windows. I checked the log file and can see that from about half way through the first sub to about the time the first sub wrapped Ekos stopped logging, uh, *everything*. It then has a small handful of log entries at around the time the sub completed, and then a gap of almost 8 hours where it woke up again. The end of the gap coincides with when I powered things down.
Not really sure what might cause this.
Log file attached. Ekos goes silent around 00:04 or so.
I think that sums it up nicely. Focus runs with the L filter, completes. Then the alignment module tries to run, changes the filter to L (which its already on), and decides focusing is needed due to the filter change. It then sends you back to the focus module.