Duh. I assumed AST/ADT was the special Arizona Time Zone. It isn't. Is it the Atlantic Time Zone used in the Canadian Maritime provinces? Arizona does not observe daylight savings and is in synch with Mountain Standard Time in the Winter. Simply changing the zone to -7.0000 and no daylight savings fixed the problem. It also made the yellow line move to approximately the right meridian.
Duh. I assumed AST/ADT was the special Arizona Time Zone. It isn't. Is it the Atlantic Time Zone used in the Canadian Maritime provinces? Arizona does not observe daylight savings and is in synch with Mountain Standard Time in the Winter. Simply changing to zone to -7.0000 and no daylight savings fixed the problem.
Duh. I assumed AST/ADT was the special Arizona Time Zone. It isn't. Is it the Atlantic Time Zone used in the Canadian Maritime provinces? Arizona does not observe daylight savings and is in synch with Mountain Standard Time in the Winter. Simply changing to zone to -7.0000 fixed the problem.
For some reason HNSKY's view of the sky has gotten "wrong." Previously, it worked flawlessly, I'm visiting Tucson, Arizona, where we are in the process of buying a home. We live currently in Evanston, Illinois. I did not bring my telescope on this trip, only my laptop. But with the night skies clear after a week and a half of what they call "monsoon" season, when the night skies are almost entirely cloudy, I decided to step outside and have a naked-eye look at the awesome sky, which is impossible...
And just to extrapolate from your answer, and the help tip, I should not even be attempting to stack planetary images, correct?
Another question on my attempts to observe Jupiter: On the stack menu is a "Planetary" checkbox. The "tool tip" for this checkbox says Checkmark this option for analysing planetary images on sharpness. Note the stacking routine is not suitable for the stacking of planetary images. Okay, what does this mean? Does it mean you should check this box when analyzing planetary images and only if you do so will the stacking routine be suitable? Or is stacking never recommended for planetary images? If the...
On the tools menu are several functions that seem to be irreversible: DE-mosaic Bayer matrix F8 Auto correct colours. F9 In particular, with the DE-mosaic Bayer matrix, there seems to be no way to revert this action, and I presume the same for Auto correct colours. F9, although this option doesn't seem to do anything to my image. I see no way to revert these actions other than File-->Settings-->Return to default settings and exit, and then reopen the file. Is there a way to undo these actions? Another...
On the tools menu are several functions that seem to be irreversible: DE-mosaic Bayer matrix F8 Auto correct colours. F9 In particular, with the DE-mosaic Bayer matrix, there seems to be no way to revert this action, and I presume the same for Auto correct colours. F9, although this option doesn't seem to do anything to my image. I see no way to revert these actions other than File-->Settings-->Return to default settings and exit, and then reopen the file. Is there a way to undo these actions? Also,...
I would concur with the original poster (and with Han). The message is confusing. Taking it further, suppose that I, a raw noob to all this, took images without any darks or flats, is stacking basically a waste of time, a lesson for next time?
So last night, for the first time I was able to capture some images of a planet - Jupiter, prominent in the eastern sky even though my area is quite light-polluted and it was a full moon. My equipment is really on the weak side - Celestron Nexstar 4se and Svbony-305. In particular, the 4se only offers manual focus and getting a really clear focus was not possible. Possibly dew was a problem, but I don't think a big one. Temperature was 80 degrees Farenheit and humidity not too bad. I have a dew shield...
I like HNSKY very much, but now it seems to have gotten into a weird mode on my Raspberry Pi that I don't know how to get out of. I start HNSKY, the screen comes up, and immediately starts advancing rapidly one day at a time, which is kind of neat in a way, but not what I want. After about a minute of this, the program must run out of memory or something and craps out. Is this a feature that I can turn off or a bug? If I can turn it off, how?
I see after looking at the Astroberry Wiki, that the author has this covered under updates in his FAQ https://www.astroberry.io/docs/index.php?title=Astroberry_Server#.E2.80.A6_but_ASTAP_isn.E2.80.98t_upgraded_using_the_normal_means.3F, but it's not easy to find. I guess he hasn't made a new release. What might have saved me a little time on your ASTAP webpage https://www.hnsky.org/astap.htm would have been some sort of notation indicating that most Raspberry Pi's still use the 32-bit OS, even if...
More and more interesting! Today I learned that my Raspberry Pi 4, although listed (on the box) as having a "64-bit quad-core Cortex-A72 processor", is shipped with an OS built on the arm7vl architecture which is 32-bit. Apparently, armhf is compatible with armv7l so the 32-bit Raspberry Pi version was the one to install. The previously installed version was also armhf. This works. Thank you.
Also, sudo apt install ./astap_arm64.deb fails with Error Code 1. Looking more closely at the output, I see this: dpkg: error processing archive /home/astroberry/Downloads/astap_arm64.deb (--unpack): package architecture (arm64) does not match system (armhf) This is interesting because when I query the system architecture I don't get armhf or arm64, I get: $ uname -m armv7l whatever armv7l is. This may explain why a recent version of astroberry includes an old version of astap.
Also, sudo apt install ./astap_arm64.deb fails with Error Code 1.
Well, the new version won't install. I downloaded this link for my 64-bit Raspberry Pi. I try to install it using the Pi's "package installer". It gives the following message: "One of the selected packages failed to install correctly. More information is available in the detailed report." I have no idea what is meant by "detailed report". A quick scan of the directory tree produces no likely suspects. I have tried installing with both the "pi" and "astroberry" usernames, with the same results. Is...
I think I've found the source of the problem with the help of Patrick Chevalley. The INDI CCD simulator is based on data that isn't good around bright stars. Aiming away from them, it seems to work.
I am using ASTAP in the following environment: Raspberry Pi 4 running Astroberry and CCDCiel with INDI drivers and HNSKY for planetarium. I am just messing around trying to learn the software as a newbie. Accordingly, my INDI devices are the CCD Simulator and the Telescope Simulator. Here are the versions in case someone might spot some incompatibility somewhere: $ apt list astroberry-server-full ccdciel hnsky h17 astap indi-bin Listing... Done astap/now 0.9.300 armhf [installed,local] astroberry-server-full/unknown,now...