Tracking drift starts only after start capture

starnet

Yes, I remember seeing behavior very similar to what you describe. There is clearly something strange going on with tracking and stacking. For example, I just looked at the time stamps of the 10-second individual FIT files for a very long exposure. The 10 seconds are actually 11, I see long sequences of either four or five files per minute, then, for no apparent reason (there were no clouds or wind, the conditions were perfect), I see an entire minute with no successful captures, then three minutes with just one or two, then the 4 or 5 files per minute sequence resumes and continues until the end. There is also a time stamp in the file name with second precision, when the process works you get a file every 11 seconds with clock work precision, but I also see entire minutes when no file is captured.

Daemn42

starnet Ya, I do see it sometimes not stack for a while, but my issue is mostly at startup. I'm thinking it might be gear lash, and whether it hits at initial exposure seems to depend on how it got to the object (basically from left or right). In a very simplistic sense when it slews to an object from right to left (in the northern hemisphere) and stops, it is leaning against the gears on the right, but it needs to start tracking from left to right which will require pushing on the left side of the output gear.
The problem is, it may start turning the motor to drive it right away, but with gear lash it takes a while before the final output gear makes contact on the left side and starts pushing it to the right. In the meantime the scope itself is not moving at all, but the stars/moon/planet/etc are moving and we get star trails and a failed stack. What I find, is that when it fails and I see that the tracking has failed, if I manually give drive it to the right just a tap or three and stop (never stop after going right to left), then there's a higher chance of it tracking from the start and capturing that first frame. Sometimes this doesn't work, but with no live view I can't know if it tries to do some final adjustment which puts it back into the gear lash area again.

Why does it fail randomly in the middle of stacking? Probably due to the dithering algo which purposely slews back/forth/up/down a little bit to ensure the sensor noise falls somewhere else on the plate and can be subtracted out relative to the fixed astro objects. Dithering can move it in any direction so it's likely that any time it happens to go right to left and stop, the next few frames probably have star trails as it takes up the gear lash again. If you save your images and scroll through them fast you can see the dithering at work. I wish it would save bad frames too. Then we'd learn a lot more.

starnet

The S50 does have a lot of gear backlash, mine has like half a degree in both Alt and Az, I measured it. I asked ZWO about this and they said it is a feature, not a bug and the backlash is required for normal operation and not to worry about it. I suspect the sudden loss of many 10-second subs in the middle of a long capture might have something to do with this backlash. The S50 does not track the target continuously like an equatorial mount would do. I am pretty sure it does not move at all during capture and compensates for the image drift electronically. After every five 10-second subs it moves to where it thinks it should be after one minute, waits for ten seconds for vibrations to die off and then takes another five shots without moving. This would explain why there are five 10-second shots per minute and if you look at the subs in sequence you can see the stars moving uniformly for five shots then doing a bigger and more random jump, then repeating. When this process works, it works really well but sometimes it might completely lose track and then it has to seek and resynchronize and during that time sub captures are lost. This seems to be unpredictable and long term efficiency can be anything from 90% to sometimes just 50%. You can never predict how long a 30-minute capture will actually take, but it will never be 30 minutes.

You can stop an acquisition to get to live view mode, then when you restart it, it asks you if you want to continue or start from scratch. So in theory it is possible to switch to live view during a long capture, then switch back to capture mode and continue without losing all the work you have done already.

Daemn42

starnet If definitely still tracks while capturing, or there would be short star trails in everything, even something as short as 1 second exposures. Super easy way to verify this. Put it in Lunar mode get it tracking properly, then manually slew it off to some bright stars. The other night I went and looked at nearby Pleiades star cluster for instance while in lunar mode. Now just push the button to stop tracking. You'll notice that the stars move quite fast across frame. Even at 1 second exposures you'd get trails if it tried to capture.

And your logic is backwards. If it didn't track for a full minute then looking at individual frames you'd see continuous movement of stars between every frame, and it would only line up (loosely) once per minutes when it resets. Instead it tracks continuously and captures 5 frames (really just 10 second capture + 1 extra second of processing) so only 5 captures fit inside a minute, and then intentionally moves for dithering purposes.

And yes any decent alt/az tracker can shoot and track at the same time while keeping everything steady.
I've also got a Benro Polaris tracker (comparable price but just a tracker) and I can do 30 second exposures while zoomed in with a long lens camera without issue.

And yes you can stop and restart on the same stack (it creates a new image but built on the previous one), but it looks to me like stack processing is about 3 full captures behind realtime, while Stop is immediate, so every time you stop you're losing 2-3 captures. Wish they'd fix that somehow.

starnet

Daemn42 Yes, any decent alt/az tracker can do what you say, but the S50 has half a degree of backlash and still achieves perfect round stars when stacking, how do you explain that? Maybe it is just my S50, but it is literally wobbly and I am still very happy with the stacked star images. I am quite impressed actually.

I am not saying the S50 does not work or that it produces bad images, on the contrary. The S50 hardware is quite OK for the price, it's the SeeStar app I have big problems with. It also works well in what it tries to do but it tries to do very little and it is far from being usable if what you want to do is more than taking a few pretty and random pictures of stars.

I do see continuous and consistent movement of stars between frames for groups of five frames, each one having perfectly round stars, then one big jump, then another group of five frames, also shifted incrementally. That's when it works and does not lose frames for a couple of minutes, I have no idea what it does then. If you want, I can upload images to prove what I say. My logic may be backwards but facts are facts.

starnet

starnet OK, maybe I am wrong, maybe I am right, that is irrelevant, but here are the facts. I looked at the first 20 sub frames of an acquisition of NGC2174 - this is from a "good" sequence, with no lost frames. The JPG of the first sub-frame looks like this (the white circle marks the star I am using as a test, which happens to be HD252464, a magnitude 10 star):

A deep zoom shows that the PSF of the star is quite round, with no trails and it looks similar in all 20 subs:

Here are the time stamps and the X and Y pixel coordinates of this star in the first 20 subs, for a 50 mm aperture, 2MPixel camera and Alt/Az tracking I think this is very good:

Does this support Daemn42's hypothesis or mine? I am no longer sure. The first five frames definitely show consistent movement in a given direction, if the S50 can continuously track each 10-second sub like he says, why can't it do that beyond 10 seconds? Sets two and three show much less movement between subs, but set 4 again shows a lot more movement. If the S50 Alt/Az mount does indeed track continuously the stars movement within the 10-second sub, why can 't it keep doing it for more than 10 seconds, or one minute or longer? And how can it do that with half a degree of mechanical backlash?

In the end, I do not care how it does it, if the lost frames are not inherent to the tracking algorithm then they are a bug and should be fixed. If there is no way to fix this, I can live with less than 100% capture efficiency, what is unacceptable to me is the very limited set of features of the SeeStar app. If I cannot at a minimum start a capture with given RA/Dec coordinates at a programmed time in the future and have it end after a given length of capture, which would let me go to sleep and keep my sanity, this thing is completely useless to me and I cannot see how I can keep using it.

I see that there are ZWO people responding to some messages posted here but they do so rarely and selectively. After my posts, which are not negative, I have stated repeatedly that the S50 has amazing performance for its cost and I am a happy customer, I am probably on a black list or something. But I desperately need these extra features in the SeeStar app because I cannot use it as it is right now.

Daemn42

starnet
Lash is not an issue as long as it's consistently tracking in one direction as it just keeps pushing on one side of the teeth. There's no need for the drive motors to switch directions. It is possible that the dithering algo occasionally reverses that direction which is why we lose a couple stacks here and there as it catches up with the lash again.

"I do see continuous and consistent movement of stars between frames for groups of five frames, each one having perfectly round stars, then one big jump, then another group of five frames, also shifted incrementally"
I just checked all my sub folders, and in those series of 4-5 frames it shows only the tiniest random direction movement of the stars in frame.
That is only possible if it's tracking continuously. If it stopped tracking for a minute as you assert everything would drift about 1/4 of the way out of frame. The big jump is the dithering algo and it's not even that far.. It purposely shifts to a slightly different position. This causes any persistent sensor noise to appear in different positions relative to the fixed stars, and over the long the stacking algo causes the shifting noise to go away while the aligned astro objects continue to stack and are enhanced. Dithering increases S/N ratio. It could also (over time) help fill in the corners a little bit which are slowly getting eaten by rotation.
They could even reduce the effect of lash while dithering if they do it this way.. To let the image "move" off center to the right, they just stop (don't try to go backwards) for a few seconds everything drifts right in frame, then start tracking again, and to make the image move to the left of center, they speed up a bit until they're past center, then slow back down to normal speed to track (same for up/down). That avoids driving it reverse direction through the backlash.

Try my test in lunar mode. You'll see everything moves way too fast all the time, to not be tracking.
There is simply no way to get crisp images of anything if you stop tracking.

Daemn42

starnet What it boils down to, is that if it wasn't tracking continuously you'd never see a sharp star. Not one. At this magnification it just moves too fast. There's no way t know what causes the tiny movements between frames. Could be it's just not quite that precise, maybe a glitch during the 1 second of processing time before it starts the next capture. Sometimes that movement is only a pixel or 3, sometimes more. Until the dithering jump.
And while you say it moves consistently in one direction.. yes, sometimes, but keep cycling and you'll see it's not consistent between sequences. First 5 might be a tiny bit right to left.. next 4-5 right to left.. or upright to downleft.. etc..

starnet

Daemn42 Maybe you are right, but in my subs it moves more than a "tiny" amount, please see my earlier post. But we are not arguing here how the S50 works, that's ZWO's business, not ours. Whatever it does, works very well for a time, then not at all for a couple of minutes, then it works again. A "30-minute" capture can take anything from 40 minutes to one hour.

If this is normal, it is what it is and we will have to live with that. If it is a bug, maybe it can be fixed. This discussion about the S50 tracking mechanism detracts from what really matters, to me at least. It sort of works and let's leave it at that. What I desperately need is increasing the usability of the SeeStar app to the point to which it matches the performance of the S50 - right now it will prevent you from using the telescope to its true potential.

Daemn42

starnet "This discussion about the S50 tracking mechanism detracts from what really matters, to me at least. It sort of works and let's leave it at that. What I desperately need is increasing the usability of the SeeStar app to the point to which it matches the performance of the S50 - right now it will prevent you from using the telescope to its true potential."

Keep in mind I started this thread to talk about a tracking glitch. Not the app.

Daemn42

BTW just to understand the math.. Earth rotates 360 degrees per 24hr which means everything is moving across the sky to the right at .25 degrees per minute. The Seestar's FoV is only about 1 degree wide which is why I said, if it stopped tracking for a minute it would move quarter of the way out of frame.
The horizontal resolution of your view is 1080px so if it's not tracking then everything moves across the view at 4.5 pixels per second. That's why you can't get a crisp star if it's not tracking.

starnet

Daemn42 I want to make the S50/SeeStar app better, you just want to prove me wrong. I am wrong, let's move on.

starnet

Daemn42 Your math is correct but your final conclusion is not. It is possible, in theory at least, to achieve a crisp star without continuous tracking, and your own post actually contains the hint to how that could be done. I agree that S50 does continuous tracking like you described it, avoiding backlash through unidirectional movement, which is why I conceded your point. This also most likely explains the sudden sequences of lost subs. If you want to discuss this further, we will have to take it offline.