Hy,

I was able to run several hours of imaging tonight, with no crashes. I had dark guiding turned on. So I believe your fixes worked!
Thanks
Wes

Read More...

I often have to observe during less-than-ideal conditions. Even with long exposures (~20sec) and 4.4 binning, plate solving is problematic.

The irritating behavior occurs thus:

Image captured
Plate-solving fails fairly quickly.
But before the failure, another image starts capture.
Then the plate solver (I am guessing here) tries to capture another image, but the camera is busy.
So it goes into wait mode, for 10 seconds IIRC.
Meanwhile, the busy capture may finish before, or after, the wait interval.
The result is a loop that takes a while to resolve, depending on the timing involved.
This sure looks like a thread or process starvation issue.

My suggestion: abort any camera captures as soon as the solver fails, to clear the error conditions.

Thanks
Wes

Read More...

Thanks, I'll try it out, but not likely for another week; we're in the middle of December rains, which is good for California, but bad for stargazing.

Read More...

I have more log files to submit from a few nights' runs. Tonight, I noticed crashes occurring whenever dark guiding started; at least there was a correlation. Not, of course, every time, but often enough. The Ekos logs show the last line before the crash, while the kstars log shows exceptions, like bad_malloc.

More error messages:

A few of these:
qrc:/qml/mount/mountbox.qml:502:17: QML MouseArea: Detected anchors on an item tha
t is managed by a layout. This is undefined behavior; use Layout.alignment instead
.
terminate called after throwing an instance of 'QUnhandledException'
what(): std::exception

and a couple of these:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

although that may have occurred once when I ran out of disk space on my external drive. Still, that should be handled a bit more gracefully, no?

FITSIO status = 107: tried to move past end of file
ffopen could not interpret primary array header of file:
/media/stellarmate/AEF6-B9DB/Capture/Fireworks/Light/NGC_6946_nofilter_Light_180
_secs_009.fits

FITSIO status = 107: tried to move past end of file

FITSIO status = 107: tried to move past end of file
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc


************************************
I tried running kstars and indiserver under EkosDebugger. But the Alignment panel doesn't function then; the UI is all disabled. Too bad, I've had crashes occur while trying to do alignment.

Read More...

I had the latest stable updates installed a couple of nights ago when I was using stellarmate.
Crashes about every 20 minutes or so. The core files are unreadable, at least by me, no stack trace.
I turned on logging, and also ran kstars from the command line and captured stdout and stderr. I saw several messages with this text:[2022-11-19T22:13:57.275 PST WARN ][ default] - Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Is there some way I can obtain a build of kstars for stellarmate with debug symbols? Then I could provide more detail. Since it appears to be Qt related, it probably has to do with user interaction, or running under vnc, or ....?

Thank you so much. With the latest Ekos interface, the old guide camera and Via selections are kind of buried in the optical train. so for my guide train, the Guider entry was empty, I changed it to the mount. Anxious to try it out later now.

Read More...

Hi

I'm having a hard time getting auto guiding to even start, never mind continue and settle so something acceptable.
The setup with which I have problems is an ExploreScientific ED102FC100, which has a focal length of 714mm and an aperture of 102mm.
The guide scope is a ZWO 120mm f/4, with an ASI120MM (not mini) guiding camera.

Many nights, I'll start autoguiding in Ekos, and the console will read "Starting forward drift in RA". Then it times out, and complains that the star drift is too short. The green dot on the drift plot doesn't move at all during this time.

This happens on both an iOptron GEM28, which I have well-balanced on both axes, and also on the new ZWO AM5, for which you can only guess balance points (no clutches)

I have had success on both mounts with a smaller scope, a RedCat 51.
I use identical ASI cameras both times, both the 533 and 2400.

How can I troubleshoot this?

1. It might just be sky conditions, I live on the coast in San Diego, and it's rare to get good conditions without marine layer or haze.
2. Could it be weight? The ED 102 is 9.5 lb, the camera around 1.5 lb, the field flattener, EFW, and EAF probably add another two pounds, so I should still be under 50% capacity of either mount (28 lb for iOptron, same for AM5 without counterweights)
3. Is the guide scope too small for the main scope?

I mucked with the parameters for calibration in Ekos, setting the pulse duration up to 2 sec, and telling it it could move as much as 20 pixels. As far as I can see, it hasn't moved at all during this process.
Suggestions welcomed!

Read More...

I already reset it on the server side to something besides "smate".
But if I click on the eyeball icon in the browser app, it tries to connect to vnc using the default password, and I never get a chance to enter credentials.

Read More...

The documentation for both Ekos and ZWO EAF mention "go to zero position". But neither one ever says how to SET zero position (drawtube fully retracted).
How do I make sense out of this? What is the function/meaning of the fields in the control panel for "Relative/Absolute/Maximum" Position?
How do I set the zero position so that I still have a couple of mm play? Same for the maximum?

If that were true, I wouldn't be able to ssh to any other device on my LAN. But I can.
I found it buried in the documentation, you use a different port, 5624.

What I still don't understand is why I couldn't add the rule for ssh on port 22 to iptables. It simply didn't work. Possibly pilot error, since it's been a long time since I mucked around at that level.

Read More...