Avocette

Yes - I’ve been successfully using the RPi 5 with KStars etc. since my December post. I first install the current 64 bit Raspberry Pi OS (Bookworm) and use the Advanced tab in sudo raspi-config to switch off Wayland and revert to X11. After that I simply follow Nou’s instructions. At the present time, the astro-build-stable script builds KStars 3.6.9 with Indi 2.0.6. All working very well (and equally well if a little less snappy on the RPi 4). One oddity, which Nou says is solvable, is that an installation built on the RPi 5 will not work on the RPi 4.

You can read all about it here: https://saimons-astronomy.webador.com/1634837_collimation-circles-3-0-is-here Did you not notice this in the post above yours?

Better post on the Stellamate forum at www.indilib.org

Better news today since the latest release of RPi OS bookworm (2023-12-05), the @nou script works again and installs KStars 3.6.8. This looks good, and seems to operate with my Astro equipment. However the Wayland features seem to have ‘lost’ the KStars main screen window control bar, so there are no exit, minimise nor maximise control buttons. This loss is intermittent and very occasionally the window control bar returns. I guess the best workaround for now may be to revert to X11.

With more in depth testing on my RPi5 I am finding that KStars 3.6.7 stable as built using @nou's script has some issues in the new GUI (WayLand) which make it unusable. Further I tried a clean install script run today on the RPi5 and the script fails at the first stage when installing dependencies. I repeated the clean install on my RPi4 and that worked for KStars 3.6.8 stable. This seems to suggest that my initial 'success' with the RPi5, sadly, was a fluke! So I have turned my attention to AstroArch 1.7.0 which @mattia has been developing. Happily he included the necessary files in the boot partition to suit the RPi5 so I have now been testing on both RPi5 and RPi4. KStars 3.6.7 runs very smoothly on both devices.

So my new RPi5 8GB arrived and I immediately imaged an RPi OS bookworm x64 and followed the @nou astro-soft-build KStars installation procedure. Plugged in my mount, cameras and Pegasus PPB, and KStars 3.5.7 all worked! (after the usual port allocation hesitation). A proper test will have to wait for a change in the weather, not likely for some days. I had expected the microSD Card to swap over and work also on the RPi4 8GB. It booted and some applications worked but not KStars. This parallels my experience with running OS bookworm on the RPi4 a couple of weeks ago and trying the @nou installation procedure. Kstars did not work in that configuration. So further tests of an updated installation of KStars 3.5.7 on the RPi4 using OS bullseye will begin later. Running @nou's script takes 3 hours on the RPi4 against 1 hour on the RPi5!

Well, my RPi5 is with customs and should be in the DHL van out for delivery at the beginning of next week. My plan is to use @Nou's method https://gitea.nouspiro.space/nou/astro-soft-build to see whether it works on RPi OS bookworm on the RPi5. Fingers crossed!

I have a Raspberry Pi 5 8GB in the post on its way to me. I have been using 32-bit Astroberry and some 64-bit installations of KStars/Ekos/Indi on RPi OS bullseye and Arch on my Raspberry Pi 4s. I tried to use @Nou's script to install Kstars etc on RPi OS bookworm on an RPi 4 without success. Anyone out there already got the RPi 5 up and running with astrophotography capture software?

At the beginning of my second age of astronomy (my first age was described in the post below), I first bought a second-hand SW 200p Dob and then immediately suffered aperture fever and longed for a 250p. I found one for sale, ironically @lawsio in Northwich, at an attractive price and bought it. Back home my (usually encouraging) wife said “why on Earth have you bought a second cannon?” I explained it was to gather 56% more photons from distant astronomical objects (according to the then prevalent SW advertising). After thoroughly cleaning and collimating the scopes, I tested them side by side during ten observing sessions, with and without a 200mm aperture mask. and decided that I preferred the 200p, and sold on the 250p. In hindsight there were many possible reasons that the 200p seemed as good if not better, most probably the figure of that particular mirror, or maybe the f4.7 versus f6.0 aperture ratio in association with my non-too-special eyepieces. )

Until my local council suddenly decided to switch off our yellow streetlights after 8pm until 6am, I had to deal with four lamps, but one predominant one. This image shows a prototype shade based on a B&D Workmate and a couple of long strips of wood with some black cloth suspended between them which I used for a while. However I later made up two shades from microphone stands fitted with a square piece of cardboard, maybe 30cm x30cm, where the microphone would have attached. Such stands proved to be relatively light and allowed very flexible positioning of the shading, and worked well so long as there were no big gusts of wind….

Take a look here https://indilib.org/forum/general/12964-astroarch-yet-another-raspberry-distro-for-astrophotography-for-arm64.html?start=72#93104 - @stefan on the seventh page, seems to be having similar issues with drivers for Touptek cameras.

The slop you talk about is a known issue that is relatively easy to deal with with a few tools and some patience. This is one of the numerous YouTube videos addressing the question.

One option might be to avoid kstars-bleeding which is always the cutting edge version. I have only had experience of the so-called ‘stable’ versions, which occasionally still have issues, but may work for you.

I am also keeping my fingers crossed that @RadekK will find the time in his present busyness to port Astroberry onto the Raspberry Pi 64-bit OS. As it happens I’m still running successfully two Astroberry installations but then I don’t suffer the issues others have been experiencing with new cameras and mounts which require Indi updates. A new installation 64-bit package I been experimenting with is called AstroArch and has been put together by another enthusiast, @mattia on the Indilib.org forum, who hopefully may have a little more ‘spare’ time to dedicate to continuing support.

You do not say whether the battery is ‘new’ or has had some earlier use. The voltages you mention are not those of a healthy lead acid battery, deep cycle, leisure or AGM type. It sounds like those of a battery that has had some earlier life! The fully charged voltage (at the terminals) should be at least 13V and after use you should never allow it to drop below 12.4V (again at the terminals) or you risk permanently damaging it. With a healthy 32AH battery this would occur when you have drawn about half the charge, ie 16AH. The ‘at the terminal’ measurement is to make certain that your wiring harness is not dropping significant voltage while the battery is delivering current.

Hi @AstroKeith Your ingenuity is very impressive! My present astrocapture software, KStars, already allows me to plate solve with any connected camera, primary or guide. So in principle I could platesolve both images and note down the offset manually, and then compensate for this offset using the manual mount control when I search for another target. At f26 and with an FOV of around 11 arc minutes square, it can be tricky to platesolve, especially in the near presence outside of the FOV of a brilliant planet like Venus. I often can get the primary image to platesolve provided I point the scope to an area of the sky with sufficient stars and no glare from a nearby planet (or worse the Moon). Hence why a stored fixed offset would be a nice feature, and as you note, with visual observing, a real bonus.

Hi @vlaiv That’s really the point - in a small grab and go system with a mini guidescope and camera like the ZWO one, it’s very convenient to use the finderscope mount without any physical alignment adjustments - this works very well for polar alignment and guiding purposes. When, for instance, I use my 275mm focal length f4.5 refractor, the offset between the primary imaging camera and the guide camera images has not been an issue in practice. However it’s just with my Maks at 1500, 1800 or 3600mm focal length that the primary image FOV is very small and the alignment offset of several FOVs becomes an inconvenience. With my larger mount and 150mm Mak, I do often use a 50mm Evoguide in adjustable alignment rings, and then as you suggest, with optical alignment the offset can be made of little consequence. My query was about any software on the market that already takes the physical offset into account.

For planetary capture, I use a Maksutov with Barlow at 3600mm (f26) and a mini-guide scope and camera fitted in a fixed finderscope mount, for initial polar alignment. Subsequently I remove the guidescope and replace it with an optical finderscope (pre-aligned) so that after a mount GoTo I can visually steer the mount to locate the desired object in the primary FOV. I would much prefer to be able to use the guidescope for GoTo platesolving except this would require it to be physically aligned to the main telescope. Does any software perform a one-time platesolve with the primary scope (at f26 of course requiring pointing at a suitable area of the sky with sufficient stars and at an appropriate exposure), then platesolve with the guidescope and calculate and store the positional offset between the two, then use this offset each time a guidescope platesolve Is needed to correct a GoTo?

I always power my AZGTi from a 12V mains power supply, but the symptoms of a fast flashing red led and then fading away sounds very much like a well used battery pack. Switch on and the mount powers up for a moment.

@AstroMuni sorry for my delay in responding. I had set the ‘Follow topic’ switch but didn’t receive any signal. Nou’s link gives full instructions. I started with a fresh Raspberry Pi OS installation and then in the Terminal window carried through the instructions in the sequence as described. After a Reboot, KStars 3.6.3 was available in the Education folder. I have followed through on FC 2.7.11 and apparently the guy (Rafa B..) who transferred it to the RPi has done so only for the 32-bit OS. He makes it quite clear in recent correspondence that he now considers the RPi as insufficient for FC and sadly does not intend to work further on the RPi platform……

A starter question for you which might help people to narrow down on your problem! - which version of KStars are you using on which OS on the RPi4 (and how much RAM does it have)?

I’m presently successfully running three Astroberrys, initially imaged in 2022 and maintained up to date with Raspberry Pi OS upgrades etc, as KStars 3.6.0 and Indi 1.9.7. Conscious and curious that there have been further ‘stable’ revisions to KStars 3.6.3 and Indi 2.0.0, I decided to try out a 64-bit Raspberry Pi Bullseye OS and install KStars using the method defined by ‘Nou’ (Dužan Poizl). https://gitea.nouspiro.space/nou/astro-soft-build It’s not a full Astroberry installation of course, since Radek included lots of extra applications like FireCapture, StarCharts, and PHD2, but if all you need is KStars, Ekos and Indi, I found it simple enough to follow for a Linux non-expert. I noted that Nou had updated it a few weeks ago, and I suppose (and hope) he will continue to do so…. I would like to install FireCapture 2.7.11 for lunar and planetary imaging, but I am not sure if the present version which works well with 32-bit Raspberry Pi OS can operate equally as well in the 64-bit OS environment.

OK - so if you carried out a sudo apt update and sudo apt upgrade that means you should be on KStars 3.6.0 and Indi 1.9.7. I had some issues with plate solving on the first couple of nights with these versions. I think that there are some features in the Alignment module in the Configuration settings which are not really default ones. The Options Profile starts out as 4-SmallScaleSolving. I had better success with choice 1-Default.

Lots of questions for clarification but firstly are you using, for instance, an Astroberry image or have you compiled your own package? and also an answer to your question - the Indi Forum is www.indilib.org/forum

‘Anyone ever run into this problem?’ Mak owners regularly run into this issue! It’s variously known as mirror shift or mirror slop and is due to the way the primary mirror slides along the primary baffle tube for focusing. Did your mount perform a meridian flip when you steered from the collimation star to the other target? Not so many Mak owners adjust collimation early in ownership, and not unless something deliberate or accidental causes a collimation shift.