I’m not sure: very short tube (85/600) and compact guidescope (50/200), so it’s not clear for me that is differential flexure. Also it will be more or less continuously and not jumps.
Other clue that make me think about problems with the mount is that if after Rutea sporting it I apply a lot of weight to the mount to “bring it down”, the jumps almost disappear.
I know, I know this is not the usual astrophotographers profile, but I’m only trying to define a use case in which this option will be useful for amateurs that’s like me, only have an introductory equipment
Another case use for the suggested "Center Object after XX exposures" will be to cope with bad behaved mounts. I'm using an old EQ5 with OnStep GOTO system attached. Sometimes, the mount "jumps" in Dec 2" or 3" without a reason (I'm begin to believe that is poor stability on the tripod/mount head combo). Between those jumps the tracking and guiding is reasonable for my image scale, but If I let the telescope unattended I usually end with a collection of perfectly tracked frames that will be drifting in Dec during the session. If you add that I'm using a small chip camera.... some sessions are completely unusable because I end keeping 60% or 50% of the field of view.
With this "Center Object after xx exposures", my chances to use all the frames will increase a lot
I’ve been using it on Astroberry for the last couple of nights. It worked fine (north vision isn’t a problem, so I’m using the “classic” way of pointing towards Polaris).
The only glitch that I’ve found is that it doesn’t likes zoom changes. For example, after the correction triangle is draw over my image if I zoom in before clicking to move the triangle, then as I click it will reverse from left to right, invalidating the procedure.
If I zoom in before the triangle is drawn (before the three measurements finished) it works as expected.
It’s a minor delight to be carried on to a more consistent alignment. Thanks for this improvement!
This is unrelated with Raspberry or KStars.
When you develop software, you store all the project history on a database called “a repository”. This number is a pointer inside the repository that identifies a concrete point in time when the problem you are suffering was not present.
With this command you are getting exactly this version of the source code and no newer.
Jerry you are right!. I've never imagined that the processor brand was used for a custom build. I'm pretty sure that this is a "bug" on the package name. I'll ask to the developers
Astroberry is running arm code, not arm64 code. The hardware is not the problem here, because the RP4 can run both kind of code depending on the OS you have installed. As I’ve said, Astroberry is armhf, not arm64
When building from sources, it install a link in the "Others" menu item on Astroberry main menu. Could you find it there?
Currently the only way to install a recent version of SiriL on the RPi is building from source. It’s not completely evident, neither extremely difficult
This are the steps I’ve followed (I think, that nothing is missing)
sudo apt install -y libgtk-3-dev libconfig-dev libfftw3-dev libexiv2-dev libopencv-dev libraw-dev libffms2-dev libheif-dev libcurl4-gnutls-dev gnuplot cmake libgsl-dev ninja-build libcurl4-openssl-dev sudo pip3 install meson==0.54.2 git clone https://gitlab.com/free-astro/siril.git cd siril git submodule sync --recursive git submodule update --init --recursive meson --buildtype release _build ninja -C _build sudo ninja -C _build install
I’m using RP4 with Astroberry via VNC from an iPad for two months now and it’s a very powerful setup. I connect the RP4 to my 2.4Ghz home network and the response time is very tolerable (it doesn’t interfere with my workflow). But I think that Maritim is the kind of user for who Asiair Pro is a better solution.
I know, inside is the same hardware and almost the same software but there is a big difference: the user don’t interact with this software. Instead he uses a native mobile app running on his powerful phone/table and only the needed data is sent from and to the RP4. This reduces some orders of magnitude de amount of data that must be transferred. Also, the user’s taps never leave his device giving him a felling of speed and feedback that VNC never will provide.
I love the control that a full Ekos provides to me, but I miss a lot the ASIAir client interface.
We don’t have any control about what the manufacturer’s SDK are doing. For example on the QHY I get 30fps full image (1920x1080) on an USB3 port. And regarding installing, there is also a .deb package on the same folder. A double click on it should do the trick without manual intervention.
Anyway happy to see that it’s working for you.