Todays version (*) is also crashing for me, on the file that last time (2 days ago) was solved, though only after very long time.
Tried a gdb backtrace - not sure if it's useful
(*) kstars-3.5.0-1537_ga8b786e88.x86_64 libstellarsolver-1.4-113_g0c587a6.x86_64
Read More...
Ah yes, now that you mention it - I had also tried binning, and that had improved results, too. I wasn't sure if binning for focus is a good idea - but given the pixel size (mine is an ASI183MC - guess that's the same chip as yours?) it's probably safe, at least for my 910mm FL...
Read More...
Quick question: What camera do you have? Is it a color one?
I recently got my first OSC, and have seen similar issues with SEP selecting weird/faint stars in AF. Switching to another algorithm for star detection did give much more reasonable selections. You can use multistar also without using SEP. Next thing I want to try is switching the camera to greyscale mode for AF.....
Read More...
xsnrg wrote: If the autofocus routine uses the offset as a starting point for the auto-focus run, that would be wonderful though.
Hmm, but it's doing that, isn't it? At least for me, the offset is applied as soon as the filter changes. Then the AF is triggered, starting from that setting.
(I have AF on filter change set for all filters, and the respective relative offsets in the table).
As for NB, it might help to use near-by BB filters. I.e., for me the focus for Hα and R is basically identical. I don't have OIII, but could imagine its focus would be very similar to G? (At least if the filters are from the same manufacturer and have the same thickness). Then do a 'fake' BB exposure to trigger AF (AF on filter change set), then switch to NB (set same offset, no AF on change).
I myself do AF on Hα, but I do have a 6nm one. That is enough to get sufficient signal in 8s exposures (ASI1600 at unity gain).
Read More...
sterne-jaeger wrote: As far as I understand it, theoretically it could happen with all mounts. With my mount for example, I've never experienced it. But from time to time I experience it during alignment, but there it does not cause any problems other that solving needs to be restarted - which happens automatically.
Ah, I think I've seen that, too, on my CEM60EC. Sometimes, in the refinement step, capture of the control frame fails, claiming the mount is slewing. So could it be that there the previous state (slew) is still reported, although the mount is already tracking again?
During flip, I think I don't have seen that so far....
Read More...
So I noticed stellarsolver finally made it into kstars. Great work Rob!
I've compiled latest git of both, to have a quick test. It's daylight at the moment, so no real star tests. I only fired up the simulators, and then wanted to use 'Load&Slew', using one of the images of last week as target. That was quite a disappointment. In the default setting it seemed to use 4 threads, and it chewed some 3-4 minutes on the image. I switched back to the old, local astrometry.net. That one's set up to use all 8 threads, and finished faster (2 minutes). But still, this is about the longest time I've seen it using here so far.
So I downgraded to the previous version (kstars-3.5.0-1442_gd604b2835). That one (also using the local installation of astrometry.net) solved the same image in 2 seconds. I assume this is because it found WCS info in the header and used that as starting point (?). So there's hope that things work better on real-sky plate solving, using the mount pointing and FOV of the camera as starter. Not sure though why the local version also took so long in the new setup. Is stellarsolver hiding info from astrometry.net that it did get in the old version?
Read More...
As he says, the BL box is greyed out, likely meaning that the driver he uses doesn't support it.
@fewayne:
- the nice image is Hys new Analyze tab. You might have to use recent/nightly builds to get that
- Take a look at the settings. You want 'SEP' star detection, and 'Linear' method with 'full field'. Then, under 'Mechanics', look at 'Initial Step Size' and 'Out Step Multiple'. The algorithm will first do STEP sized steps, then half of that. So it should be small enough that it's in the order of your desired accuracy. I use 20. The step multiplier will give you two things: STEP times multiplier should be large enough that the star gets unsharp, but still small enough that you are within the clear slope of the V curve. In addition, it will do the same overhead as backlash compensation. I.e., use 20 and 5 -> initial step is 100. So it will move 200 out, then 100 in, then continue to move inwards in steps of 20. So for your case, that step should be larger than your backlash. Keep those three points in mind, then it should work nicely...
Read More...
Just for verification - you take the meridian line drawn by KStars as 'reference' that defines the true meridian, yes? Could also be the mount is right and the line is drawn wrong.....
Read More...
Whee! Indeed, that works. Didn't even know about that option 
But Hy's patch already made it to the main repo 
Read More...
hy wrote: Pit,
I'd be happy to help, I introduced this log just for people like you who want to use phdlogview, however let me know what you think...
So, are you saying that the moment dithering starts (i.e. it changes its target pixel values, but hasn't even pulsed the mount yet) the 'Settling Started' message should be printed?
At least this is how it's done in PHD2:
INFO: SET LOCK POSITION, new lock pos = 222.368, 725.819
INFO: DITHER by 1.086, 1.738, new lock pos = 223.256, 727.666
INFO: SETTLING STATE CHANGE, Settling started
523,2270.786,"Mount",-0.889,-1.847,-1.086,-1.738,-1.086,-1.738,122,E,135,N,,,1491138,370.14,0
524,2274.840,"Mount",-1.669,0.828,-1.569,1.133,-0.863,0.906,97,E,70,S,,,1874636,429.01,0
525,2278.868,"Mount",-0.313,-0.817,-0.400,-0.742,-0.220,-0.594,25,E,46,N,,,1486827,280.59,0
526,2282.955,"Mount",0.328,-0.087,0.317,-0.148,0.000,0.000,0,,0,,,,1557053,241.27,0
INFO: SETTLING STATE CHANGE, Settling completeThat is well true...If that's the case, then why do they even bother with a 'Settling Started' message. They could just use the "DITHER by" message.
I can well follow there. But what it leads to is that I always get the 'started' message directly followed by the 'settled' message. And as the INFO entries don't have timestamps that effectively is a zero settling. But TBH, I would indeed rather take the new lock point as something that cancels the 'settled' state, taking the settling as the time it needs to reach that new position. So I think both views have an argument...The way I implemented it, was to put the settling started message after the dithering was complete (i.e. it changed the target, pulsed the mount a few times to get 'close enough' to the target). Then, there is a Settle parameter in Guide Options, which means "after the dithering is done, wait N more seconds before starting to capture (defaults to 0)." This (potentially 0-second-long) settling interval is what you're currently seeing.
It seems to me that you're pointing out a bug in phdlogview, more than one in KStars. However, from a practical point of view, it may be easier to fix KStars, as this log is really only useful for phdlogview.
What do you think, should it be changed in KStars?
Hy
I'd say yes. As you write, the log was set up in a way to be compatible with PHD2 and especially phdlogview. So it would be more straightforward to take the pragmatic approach and copy it's view of things (even if you'd rather consider it wrong). But unless you can convince Andy to change phdlogview (and probably also PHD2), not doing it would reduce the 'user experience'.
My 2¢
Read More...