Not the Mount, but the Camera?

anjin_nav

I have had the ASIAir Pro and now the ASIAir Plus on two different mounts. The first mount was a SkyWatcher EGM-35 Pro. My current mount is the iOptron HEM44EC. With all these combinations, I've had issues where at some point or another during the night--usually following a meridian flip, but sometimes for reasons I can't explain--the ASI decides to plate solve to recenter the target. It will successfully plate solve, then decide it's off target, and issues a command to move. It then plate solves again, decides the target is off-center, and commands a new slew. This happens over and over again, until I catch it. I've attached a log from a session earlier this month.

autorun-log-2023-02-03-203826.txt

42kB

The one thing that's been in common has been my camera--a Nikon D850 DSLR (48 MP). In the past, I thought I noticed that the ASIAir would command a shot, then another, but the next shot was identical to the last--even when focusing. In fact, when focusing, I know I have to wait for every other shot before I try a new setting. To test this hypothesis, using Subframe Selector in PixInsight, I started graphing the FIT files ASIAir saves to the USB versus the RAW files my camera stores locally. The RAW files graph as you'd expect, with random spike in PSF weight. The FIT files, however, graph in a pattern where almost every shot is followed by a shot with the same PSF weight. From that, it appears the ASIAir isn't saving every shot, but rather is saving the same shot twice. I've attached a PDF of a representative graph.

m81-psf-signal-weight-graph.pdf

135kB

Now to my overall hypothesis. I think perhaps what is happening is that at some point the ASIAir commands a GOTO, then centers. It takes a shot to plate solve, and decides the target isn't centered, so it calculates a change and commands the mount to move. It takes another shot to plate solve, but instead of an updated photo, it's using the first photo. In that case, it calculates an even bigger change, and commands the mount to move. This time the shot the ASIAir plate solves is new, and definitely not on target, so it commands a move. It shoots, plate solves on a duplicate, calculates yet another erroneous move, commands a move, and so on.

The only way I can think of to test this hypothesis is with another camera to see if the issue is resolved. Unfortunately, I don't have another camera at my disposal.

Long post, but i have three questions:

Are others having this same problem, and what camera are you using?
Is my hypothesis reasonable?
Would someone who does have both be willing to test it?

Thank you.

w7ay

anjin_nav With all these combinations, I've had issues where at some point or another during the night--usually following a meridian flip, but sometimes for reasons I can't explain--the ASI decides to plate solve to recenter the target.

The recentering after a Meridian Flip if controlled by the "GoTo Auto-Center" switch in the Mount settings window.

If, after turning it off, you are still getting autocentering, there is a bug somewhere.

It will successfully plate solve, then decide it's off target,

That is definitely a bug if it slews farther and father away each time (I think you meant that since you mentioned having to catch the OTA).

Can you check if the mount has a pier side parameter (it will usually say Pier East or Pier West) in its hand controller? The pier side should switch after a Meridian Flip. If it did not (or if ASIAIR had send the mount the wrong pier side through a command), then what you observed would be the one of the effects (each sync and goto after a plate solve moves the center of your plate farther and farther, instead of closer).

It takes a shot to plate solve, and decides the target isn't centered, so it calculates a change and commands the mount to move.

I don't think the ASIAIR itself is calculating a change. The mount does.

What the ASIAIR does is to take an image, and then solve for the center of the image frame (the so called "plate solve process," "plate" is just short from the term "photogtraphic plate" used by real astronomers -- see here: https://www.nps.gov/parkhistory/online_books/butowsky5/astro4f.htm )

After computing the center of the plate (using algorithms, database, and probably code, from astrometry.net), ASIAIR sends the center to the Mount as a "Sync" command. What the sync command does is to tell the mount "you are not where you think you are, you are here, instead").

The mount thus change its current RA and declination registers to obey.

After the sync, ASIAIR would send a target GOTO to the mount. Since the mount no longer thinks it is pointed at the target, it will make that correction. Rinse and repeat, and you get closer to the target -- unless you have changed the coordinate sytem (a wrong pier side will do that to you, for example, in which case the movements will be progressively away from the target).

Chen

anjin_nav

Thank you, Chen. This is useful. My question remains, however, and perhaps is actually even more relevant.

Going with my theory that the ASIAir is only able to store every other photo (I believe this is because I'm using a rather old camera with a large file size via USB3), I think my logic stands. ASIAir plate solves, and tells the mount where it thinks it should point. Dutifully, the mount responds. ASIAir then plate solves again, but on the same "plate." It tells the mount it should point "here," and the mount tries to comply. ASIAir then plate solves, but this time it's on a fresh photo. This one isn't the target either, so it tells the mount it's pointing incorrectly yet again. The mount moves to what it thinks is the new correct orientation--and so on.

The biggest issue I have with this theory is that my new mount has an encoder (relative). Shouldn't the mount be smarter than to simply follow the ASIAir?

Regardless, I can think of no other explanation for the seeking behavior over two mounts and two ASIAirs--except user error. In that case, however, I have no idea what I'm doing wrong.

As for plate solving, by the way, I'm showing my age, but I actually took a summer astronomy class in college where we used photographic glass plates. Much different than the modern digital equivalent. 🙂

w7ay

anjin_nav I'm showing my age, but I actually took a summer astronomy class in college where we used photographic glass plates.

I started grinding my first mirror in 1963. But did not look through a professional optical telescope until the 1970s (I had encountered many radio telescopes though, due to two summers in the late 1960s at the National Radio Astronomy observatory). One year, while I was a grad student, George Herbig (the discoverer of the Herbig-Haro objects) was teaching an undergrad class on astronomy at Stanford as a visiting professor, so I decided to take that class just because he was Herbig. At the end of the quarter, he got the class a whole night for ourselves with the 36" Lick refractor (back then, San Jose was also not as light polluted as today).

The biggest issue I have with this theory is that my new mount has an encoder (relative). Shouldn't the mount be smarter than to simply follow the ASIAir?

It depends on how the encoder is implemented -- whether the mount's algorithm take the "sync" location as an additional fixed offset, as all mounts that I know do. I have no problem with my mount that has a relative encoder (RST-135).

The thing about the encoder-is-the-culprit hypothesis is that if the encoder has priority, the mount will always go back to the same location -- instead of creeping away from it.

Chen

anjin_nav

I'm impressed! I wish I'd stuck with astronomy. It's been a long, long break between now and then for me.