So,

Some progress on the crashes - it no longer crashes. Now it hangs instead. I get the infamous "The app is no longer responding - Wait or force quit" dialog.

The tail of the log is consistently this:

[2020-10-29T14:13:33.987 EDT DEBG ][ org.kde.kstars.ekos.guide] - Capturing frame...
[2020-10-29T14:13:35.427 EDT DEBG ][ org.kde.kstars.ekos.capture] - Autoguiding suspended until primary CCD chip completes downloading...
[2020-10-29T14:13:35.430 EDT DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Guiding" to "Suspended"
[2020-10-29T14:13:35.430 EDT INFO ][ org.kde.kstars.ekos.guide] - "Guiding suspended."
[2020-10-29T14:13:35.431 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Suspended"
[2020-10-29T14:13:35.462 EDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/jeremy/FlipTest/Light/Luminance/FlipTest_Light_219.fits"
[2020-10-29T14:13:35.462 EDT DEBG ][ org.kde.kstars.fits] - Reading file buffer ( "11.6 MiB" )
[2020-10-29T14:13:35.627 EDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 2.72458
[2020-10-29T14:13:36.001 EDT DEBG ][ org.kde.kstars.fits] - FITHistogram: JMIndex 0.999979
[2020-10-29T14:13:36.011 EDT INFO ][ org.kde.kstars.ekos.capture] - "Download Time: 0.58 s, New Download Time Estimate: 0.64 s."
[2020-10-29T14:13:36.091 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 219 out of 600."
[2020-10-29T14:13:36.093 EDT INFO ][ org.kde.kstars.ekos.capture] - Resuming guiding...
[2020-10-29T14:13:36.094 EDT DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Suspended" to "Guiding"
[2020-10-29T14:13:36.094 EDT INFO ][ org.kde.kstars.ekos.guide] - "Guiding resumed."
[2020-10-29T14:13:36.095 EDT DEBG ][ org.kde.kstars.ekos.guide] - Capturing frame...
[2020-10-29T14:13:36.095 EDT DEBG ][ org.kde.kstars.ekos.guide] - Received guide frame.
[2020-10-29T14:13:36.095 EDT DEBG ][ org.kde.kstars.ekos.guide] - Multistar: findTopStars 25
[2020-10-29T14:13:36.095 EDT DEBG ][ org.kde.kstars.fits] - Sextract with: "1-Default"
[2020-10-29T14:13:36.095 EDT DEBG ][ org.kde.kstars.fits] - Reading file buffer ( "289.7 KiB" )

Again this seems to be in the SEP guiding. It hangs trying to read the buffer.

J.

Read More...

rlancaste wrote: I might be reading this wrong, because it is fairly late in the evening for me, but it looks to me like this crash occurred in KStars during guiding, after StellarSolver returned the star list, but before the method to find the guide stars completed? Perhaps the list was still needed and it got deleted in KStars too soon? I will send this to Jasem and see if he agrees.


I did some more digging and have come to the same conclusion - it's related to guiding. I switched guiding to not use SEP at all, and my test ran smoothly for 10 hours. It's not done that before with the stellarsolver branch.

I see Jasem has made some changes, so I will pull that and see if it improves things.

J.

Read More...

I'm having definite stability issues with stellarsolver. Align seems to be working fit, but running a dummy sequence with the simulators is failing somewhere in the FITS processing post capture. This has been consistent over the last few days as I have been keeping up with the changes. The SEGV goes not always occur in the exact same place, but it always occurs when doing analysis. I turned off all of the HFR calculation options and WCS load options for FITS and Ekos, but it still seems some calls go out to stellarsolver.

I am also guiding (simulated) at the time, so perhaps there is a race condition between SEP in guiding and SEP in FITS analysis. I'm not sure of any of the changes made it across to guiding yet. There are references to guiding in the backtrace, but I have no idea if that has any relevance or not.

The back trace from the core dump is attached.

J.

Read More...

knro wrote: Thanks folks for all the testings. Nightly release now is not stable, please use v3.4.3 until the nighties are settled a bit. Do not use nightlies for production, just to test the new features and help us track any issues which is greatly appreciated.


I plan to keep "Twilight Testing" and using marginal nights for testing. I echo Jo's sentiments.

J.

Read More...

With all of the changes going on, stability has definitely got worse on the nightlies. This is a worry because there has been a lot of change without a pause to address instabilities that inevitably get introduced. The more change without a pause, the harder it will be to get that stability back. I was using them with some confidence. With the weather as it is for me now I will be using either the stable kstars or my windows platform, probably the latter because it has been more stable than even the stable kstars build. I can't afford the lost imaging time when I'm getting one or two days a month right now.

What I do find perplexing is that my crashes are happening in an area that should not really be impacted by the bigger stellasolver changes. When it core dumps, it always does so just after starting a new capture. This points to something nasty, insidious and hard to track going on. I need to change the ulimit I guess so I can get a core dump and stick it in GDB. Maybe it will be consistent and easily tracked.

J.

Read More...

I'm running tests now from a kstars built from aca1aa04218e972eeb06c1ca2f994f8a07fc1763.

All is working with simulators, and simulators/actual mount. I did have random crashes last night. Waiting to see if this mornings build is more stable.

This is with guiding, focusing and aligning enabled.

J.

Read More...

Glad it wasn't just me!

I've just pulled Jasem's latest commits from the extractor branch and built it.

With the simulators it's now working. I'll update the kstars instance on my RPi tomorrow and test it with my Losmandy mount and camera simulator. I'm doing that anyway trying to run to ground my meridian flip issues, which I think I have licked (yay!)

Not sure when Jasem is going to merge that branch into the official nightlies.

J.

Read More...

Using all simulators and setting up a simple schedule to just slew and capture a few frames, the scheduler times out waiting for the mount. This was built from commit 58aabb619228c24c4e7101d8ef2e0ab6b93fb777.\


The log file is attached, but there is a very suspicious set of messages:

[2020-10-19T22:22:31.395 EDT WARN ][ default] - QObject::connect: No such signal org::kde::kstars::Ekos::Mount::ready()
[2020-10-19T22:22:31.395 EDT WARN ][ default] - QObject::connect: (receiver name: 'Scheduler')
[2020-10-19T22:22:31.395 EDT WARN ][ default] - QObject::connect: No such signal org::kde::kstars::Ekos::Mount::newStatus(ISD::Telescope::Status)
[2020-10-19T22:22:31.395 EDT WARN ][ default] - QObject::connect: (receiver name: 'Scheduler')

It looks like the signals from the mount to the scheduler regarding status are not getting through.

J.

Read More...

El Corazon wrote:
Are these the new options you are talking about? Works perfectly for me, with a short refractor, at least.


Yes, and they are not working for me on my SCT. The classic SCT donuts were throwing it way off, and even close to focus I was not picking up many stars. Reverted to an earlier build and all is now well and getting data around 0.7"/px. with guiding RMS at 0.79". SEP Multistar autoguiding is fantastic.

One of the other profiles may have worked better, but this change was unexpected and there seems to be little background reading to help figure out what to do. Before using a nightly I usually do some testing with the simulators and sometimes my actual mount along with the camera simulator. The two things you can't really test this way are autofocusing and guiding because there are so many optical and mechanical dependencies.

J.

Read More...

rlancaste wrote: In terms of the number of options as well. I don't really know what options to include because there are a lot of options for SEP. I found that just a few tweaks to the options, really really improved things. So when I started working on this back in February/March, I kept begging people to help me figure out which options were best, which options to include, which options to leave out, and help in tuning a set of good options. While I got tons and tons of great help with testing and suggestions, we really needed more help ironing out the options. So in the end, I just left almost all of them in the editor, until people can tell me more about which options are helpful and which ones are not, I really don't think I should remove any until we get more feedback on them. But I'm hoping you are not overwhelmed by them. Hopefully as I said in my last post, most people won't even need to touch them.


The problem you are going to run into in asking about options is that you are only going to get valid feedback from a very small group of users who understand all the options. I certainly don't understand them. And that's a really, really difficult issue to solve. For reference, I manage a team of over 100 engineers doing software and systems engineering, and I am faced with the exact same issue every day. How do I take a complex problem and make it usable and understandable for my users who are not aware of the underlying complexity. So I feel your pain.

The key will be getting a set of defaults that works for the majority of the users. That was case prior to stellarsolver, and a month or two down the road we will hopefully be back there.

I do think the missing piece here is guidance. This is a big change, and there is nowhere to go that I am aware of to even begin to understand how to tweak things to improve matters, and from that provide feedback. What is All Stars? What is Parallel Small Scale & Parallel Large Scale? I don't expect you to answer that here BTW, it's somewhat rhetorical.

If there was a wiki that described the changes and describe the impact of the changes along with some guidance on how to debug and experiment, I think you may have gotten better feedback.

Overall, this is a good change, and I see the validity of it from an architectural perspective. I will continue to play with the nightlies (although the weather does not look like it will cooperate much over the next week or so)

J.

Read More...

It seems that auto focus is now broken also,

I was trying to autofocus my SCT with a moonlight and was getting very poor star recognition. I then noticed that auto-focus now has an editor that brings up the stellasolver options. I reverted to a pre-stellasolver build, and autofocus with sep is working perfectly.

I hate to say this, but if I have to manage the myriad of stellarsolver options to get autofocus working then I'm off back to windows and ASCOM (sadly - i really like my Rpi4 as a capture device).

I appreciate that this is still early days, but I think that this change needs a lot more thought and work. This is on top of having a lot of issues getting solving to work with it as well.

My overall comment is that something that just worked for the most part has become way too complex and requires way too much tuning, with way too many options. Options are nice, but when something that for the most part just worked gets replaced by this, and it is this fragile, it's a real turn-off.

IMHO this should have stayed on a branch instead of being in the nightlies, or the rollout should have been much slower and more measured.

J.

Read More...

Jeremy Burton created a new topic ' Ekos align module and rotators' in the forum. 3 years ago

I have a question on how rotators work with Ekos and align. There is no rotator simulator so my usual approach of try it out and see doesn’t work.

It I have a rotator then I guess the rotator button on the capture tab is enabled, and I can enter a rotation angle from celestial north in it.

I am assuming that the align module, as well as doing a closed loop slew, will also do a closed loop rotate to match the entered field rotation. I’m also assuming the the mosaic wizard will also correctly prefill the rotation angle.

Can some confirm this please. I’m looking very hard at getting a rotator and I’d rather not be forced to go back to windows based software to get these capabilities.

Thanks

J.

Read More...