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...