Greg's profile

OK, found the config not in ~/.local/share/kstars but in ~/.config/kstarsrc. Changed to DitherEnabled=false and I'm back.

Read More...

Hi,

I'm running a build from a git checkout dated back to Nov 15, 2020. It's been stable enough, but I made a config change (guiding and non-guiding dither enabled concurrently) and Ekos crashes every time with a message they can't be run together. I can't get in quickly enough to disable one or the other.

Is there a way I can revert this in a config file? I can't figure out where it is.

Greg

Read More...

Under the guide tab, verify that the "Via" setting is the same method for both setups.

Read More...

I have seen something like this as well but haven't dug into it yet. I usually just make sure the mount is unparked before starting Ekos.

What mount are you using?

In my case I am using a paramount with TheSkyX as the connection point.

Read More...

rlancaste wrote: So based on what I am hearing, different options might be working better for the "load and slew" type function vs the "capture and solve" function?

Possibly a factor is the load and slew images might be longer exposures compared to relatively short captures for alignment?

Read More...

rlancaste wrote: Thank you for doing some testing!

You are very welcome. It's the least I can do to help out. If only I knew C++... Another year perhaps.

I am confused by your first issue: "BTW - when testing with the simulators I left the Solver Action as "Nothing" but the slew still occurred". I think this is a miscommunication in the interface. If you clicked the "Load and Slew" button then it is always supposed to slew to the target. The selections for the Solver action are only applicable if you click "Capture and Solve"

Agreed that it is probably an interface communication issue. It would probably be better to have the button as "Capture & Solve", "Load & Solve" with the Solver Action section giving options "Slew To Target", "Solve Only", and maybe a checkbox for "Sync" in cases where people want the slew and sync to happen. Probably outside of the scope of this topic though - I was sharing as an FYI.

" after the unwanted slew, the Load and Slew button was now greyed out." So was this after it arrived at its target after the slew you mentioned? The buttons should be disabled while it is slewing, but after it gets there they should re-enable. If not, that could be a KStars bug.

Correct - The slew occurred and failed (because I'm using sims and don't have images set up I guess). The Load and Slew button stays greyed out - only the Capture button can be activated.

" image has some problems including mystery stars". Do you mean that it detected noise as stars? This is certainly possible depending on your selected options profile. We are trying to develop better options, but they aren't quite perfected yet. Did you only try the one profile or did you try any others?

Nope - that first image has some "mystery stars" in them that are not present in other images of the same object. My guess is this is a residual bulk image problem that came with switching the camera's mode? Not sure though. I guess the point is that the solver performed well in spite of these mystery stars. I was surprised it didn't confuse the solver.

"However, this one of the same field does not solve. The main differences I can determine is the median signal of this frame is higher than the other two and the image is rotated 180deg from the others." I downloaded this file and it solved quickly. Which profile are you using to solve?

I'm using whatever default was selected when I built the software with SS included the first time. Looks to be 4-ParallelSmallScale. I find it interesting that some of the images of the same object with similar characteristics solve, but some do not. Maybe these images are right at the edge of some threshold.

" Interesting that it says it needs 19.7GB of RAM. Is that true?" So the way astrometry's "load all indexes in parallel" option is supposed to work is that it loads all your index files into memory simultaneously, at least according to their documentation. This of course will make it much much faster than loading each index file one after the next. But if you have bigger index files than available RAM, this could be serious problem. I am not sure that it always will use that much RAM and if you have SWAP files or ZRAM, that could certainly prevent any crashes that could occur from taking up all the RAM, but I don't want to risk crashes, so in the code right now I calculate how much RAM there is and how big the indexes are and report that and disable the option if it is too much. We can play around with that to see if it really does take that much, but for now, I'm being cautious.

Gotcha. Happens to be I have 32G in this PC and I had forgotten about that detail. It's working, and it's fast enough that by the time I switch back to the Ekos window after loading an image that it's already solved. I'll have to try this out on lower memory systems soon.

Thanks again for your work on this!

Greg

Read More...

I'm running builds of kstars and indilib from relatively fresh pulls performed in the last week. This problem may have been occurring prior to now but I'm not sure.

I've noticed that time in kstars will get stuck at some point. Log files and FITS headers seem to continue with the correct time. This morning I found that the LT indicator in kstars as well as the log windows stuck at 21:38:32 LT while it is presently ~07:30 LT. Looking at the camera tab I see the ~20 or so exposures and associated activities (focus, dither) logged at 21:38:32 LT. I had enabled GPS logging, and see the system time being set properly at the beginning of the session, but no indication of time being frozen or other indication that something broke.

This is a short snippet of the camera tab log that shows how the time gets stuck:

2020-10-22T21:38:32 Dithering...
2020-10-22T21:38:32 Received image 2 out of 4.
2020-10-22T21:38:32 Download Time: 5.68 s, New Download Time Estimate: 5.30 s.
2020-10-22T21:38:32 Capturing 900.000-second B image...
2020-10-22T21:38:32 Focus complete.
2020-10-22T21:38:32 Dither complete.
2020-10-22T21:38:32 Dithering succeeded.
2020-10-22T21:38:32 Dithering...
2020-10-22T21:38:32 Received image 1 out of 4.
2020-10-22T21:38:32 Download Time: 6.17 s, New Download Time Estimate: 5.22 s.
2020-10-22T21:38:32 Capturing 900.000-second B image...
2020-10-22T21:38:32 Job requires 900.000-second B images, has 0/4 frames captured and will be processed.
2020-10-22T21:38:30 Received image 4 out of 4.
2020-10-22T21:38:30 Download Time: 5.42 s, New Download Time Estimate: 4.99 s.
2020-10-22T21:38:30 Capturing 900.000-second B image...
2020-10-22T21:38:30 Focus complete.
2020-10-22T21:38:30 Dither complete.
2020-10-22T21:38:30 Dithering succeeded.
2020-10-22T21:37:28 Dithering...
2020-10-22T21:37:28 Received image 3 out of 4.
2020-10-22T21:37:28 Download Time: 4.82 s, New Download Time Estimate: 4.84 s.
2020-10-22T21:22:25 Capturing 900.000-second B image...
2020-10-22T21:22:25 Focus complete.
2020-10-22T21:20:51 Dither complete.
2020-10-22T21:20:51 Dithering succeeded.
2020-10-22T21:19:44 Dithering...

Investigating the GPSD tab I saw that most of the fields were gone including lat/long. Unfortunately I didn't get a screen capture. The last log entry showed that GPS fix was obtained about 11 hours prior. I clicked on the Refresh GPS button which caused the GPSD read error to start piling up. Disconnecting/reconnecting the driver fixed it and proper time was re-established. The gpsd daemon itself was stable and showed no issues during this time.

2020-10-23T14:37:30: [ERROR] GPSD read error. 
2020-10-23T14:37:28: [ERROR] GPSD read error. 
2020-10-23T03:35:45: [INFO] GPS fix obtained. 
2020-10-23T03:35:03: [INFO] GPS fix obtained. 
2020-10-23T03:35:01: [INFO] Device configuration applied. 
2020-10-23T03:35:01: [INFO] GPS Update Timer disabled. 
2020-10-23T03:35:01: [INFO] Loading device configuration... 
2020-10-23T03:35:01: [INFO] GPS fix is in progress... 
2020-10-23T03:35:00: [INFO] Debug is enabled.

Logfile attached.

Greg

Read More...

Hi Rob,

I finally had a chance to do some testing with StellarSolver. I'm running a build from kstars commit 15ba3c90a1ec4724a28b43cfa69fa1fb6693242a and SS commit b8ce7148a1bad6f9dd4f5d8b4c4ef95396db4a3c.

I had been using ASTAP. I switched the solving method to "Internal solver" and left all settings as-is. I then ran Load and Slew and it just worked out of the box - no problems, generally. However, I did find a failure case that I'll share here.

BTW - when testing with the simulators I left the Solver Action as "Nothing" but the slew still occurred. Also, after the unwanted slew, the Load and Slew button was now greyed out. To recover it I had to stop/start the indi services.

The following image solves with no problem, even though the image has some problems including mystery stars.

https://www.dropbox.com/s/20kh08zb0xhc1y5/ic63_Light_L_900_secs_2020-10-18T21-35-21_001.fits?dl=0

This one works as well, without the mystery stars:

https://www.dropbox.com/s/4lx6wqjxu40lll6/ic63_Light_L_900_secs_2020-10-18T21-52-38_002.fits?dl=0

However, this one of the same field does not solve. The main differences I can determine is the median signal of this frame is higher than the other two and the image is rotated 180deg from the others.

https://www.dropbox.com/s/cfxuw6xdln8qjc5/ic63_Light_L_900_secs_2020-10-20T05-10-04_040.fits?dl=0

I've attached the log file with Alignment logging turned on. Also, below is from the log window on the alignment tab. Interesting that it says it needs 19.7GB of RAM. Is that true?

Greg

2020-10-22T09:40:09 Solver Failed
2020-10-22T09:40:09 internal pixel buffer full
2020-10-22T09:40:00 Starting Internal StellarSolver Sextractor. . .
2020-10-22T09:40:00 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:40:00 There should be enough RAM to load the indexes in parallel.
2020-10-22T09:40:00 Evaluating Installed RAM for inParallel Option.  Total Size of Index files: 19.7149 GB, Installed RAM: 31.2902 GB
2020-10-22T09:39:35 Solver Failed
2020-10-22T09:39:35 Solver was aborted, timed out, or failed, so no solution was found
2020-10-22T09:39:35 Starting Internal StellarSolver Astrometry.net based Engine. . .
2020-10-22T09:39:35 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:39:35 Image width 640 pixels; arcsec per pixel range 0.93949 1.76154

2020-10-22T09:39:35 Scale range: 10.0212 to 18.7898 arcmin wide

2020-10-22T09:39:35 Set odds ratio to solve to 1e+9 (log = 20.7233)

2020-10-22T09:39:34 Configuring StellarSolver
2020-10-22T09:39:34 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:39:34 Starting Internal StellarSolver Sextractor. . .
2020-10-22T09:39:34 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:39:34 There should be enough RAM to load the indexes in parallel.
2020-10-22T09:39:34 Evaluating Installed RAM for inParallel Option.  Total Size of Index files: 19.7149 GB, Installed RAM: 31.2902 GB
2020-10-22T09:39:34 Image received.
2020-10-22T09:39:29 Capturing image...
2020-10-22T09:39:23 Slewing to target coordinates: RA (00h 59m 30s) DEC ( 61° 05' 18").
2020-10-22T09:39:23 Solution coordinates: RA (00h 59m 30s) DEC ( 61° 05' 18") Telescope Coordinates: RA (12h 45m 39s) DEC ( 90° 00' 00")
2020-10-22T09:39:23 WCS information updated. Images captured from this point forward shall have valid WCS.
2020-10-22T09:39:23 Solver RA (14.55265) DEC (60.97575) Orientation (0.22974) Pixel Scale (0.73429)
2020-10-22T09:39:23 Field parity: pos

2020-10-22T09:39:23 Field rotation angle: up is 0.229738 degrees E of N
2020-10-22T09:39:23 Pixel Scale: 0.734292"
2020-10-22T09:39:23 Field size: 55.0635 x 44.0628 arcminutes
2020-10-22T09:39:23 Field is: (-196.752, 50.8996) deg from search coords.
2020-10-22T09:39:23 Field center: (RA H:M:S, Dec D:M:S) = (00:58:12.637, +60:58:32.700).
2020-10-22T09:39:23 Field center: (RA,Dec) = (14.5527, 60.9758) deg.
2020-10-22T09:39:23 Solved with index:  4109
2020-10-22T09:39:23 Number of Matches:  11
2020-10-22T09:39:23 Solve Log Odds:  72.9335
2020-10-22T09:39:23 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:39:22 Starting Internal StellarSolver Astrometry.net based Engine. . .
2020-10-22T09:39:22 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:39:22 Scale range: 0.582152 to 0.873228 arcsec/pixel

2020-10-22T09:39:22 Set odds ratio to solve to 1e+9 (log = 20.7233)

2020-10-22T09:39:22 Configuring StellarSolver
2020-10-22T09:39:22 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:39:22 Stars Found after Filtering: 50
2020-10-22T09:39:22 Keeping just the 50 brightest stars
2020-10-22T09:39:22 Removing the stars with a/b ratios greater than 1.5
2020-10-22T09:39:22 Stars Found before Filtering: 20397
2020-10-22T09:39:18 Starting Internal StellarSolver Sextractor. . .
2020-10-22T09:39:18 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2020-10-22T09:39:18 There should be enough RAM to load the indexes in parallel.
2020-10-22T09:39:18 Evaluating Installed RAM for inParallel Option.  Total Size of Index files: 19.7149 GB, Installed RAM: 31.2902 GB
2020-10-22T09:38:29 World Coordinate System (WCS) is enabled. CCD rotation must be set either manually in the CCD driver or by solving an image before proceeding to capture any further images, otherwise the WCS information may be invalid.
2020-10-22T09:38:29 Idle.

Greg

Basic Information

Gender

Birthdate

About me

Contact Information

State

City / Town

Country