Rallemikken

4 hours ago, phil18 said:

The problem is I am using a X2 barlow so my field of view is narrowed down expecially if photographing the moon.

Well known problem with cameras fitted to scopes designed for visual. The simplest is to move the primary mirror upwards in the tube.  Most often, 15mm is enough. Plenty of guides on this.

1 hour ago, dph1nm said:

The indi_canon_ccd driver would never recover from powering down the camera to replace the battery, to the extent that it required a reboot of the pi to get the system back.

That's right, same issue as with my 5D MkII when I used the faulty battery adapter. The indiserver process is designed to pick the devices up after a failure or disconnect, but that doesn't always work, at least not with the indi_canon_ccd driver. But a reboot is not requiered. Kill the process that runs the specific server and start it up again. When I run a dedicated Pi as a indiserver only I SSH into it and start each server in it's own terminal window. For the Canon it will be "indiserver indi_canon_ccd". If things go sour, you just terminate the process with Ctrl+C and restart it. Camera should connect and work as expected. If the server is started automatically you have to find the right process ID (ps aux | grep indi) , kill it (kill <PID>) and restart it (indiserver <your_indi_driver>). If I understand this right, the indiserver process spawns once for each driver. Each server instance is independent of the others, bur several can be started at once with one command: "indiserver indi_canon_ccd indi_eqmod indi_asi_ccd" and so on....   Once up and running, they are seperate processes.

17 minutes ago, dph1nm said:

My 1000D works fine with the indi gphoto_ccd driver. It never played well with the specific canon_ccd driver though (messed up the pi usb ports)

In many ways. they are the same. No problem running a Canon DSLR on  indi_gphoto_ccd driver, but the specific indi_canon_ccd offers some advantages. I'm not a (seriuos) hacker, but I've seen images from my 600D roll into my HP EliteDesk at less than a second, on a 5 metres extension cable. On my current setup, a RPi4, it needs 4-5 seconds. No big deal, the Pi is rock solid, but there is something going on behind the scene, hardwarewise. In the race for speed, especially on all these new SBC's, the width of the data transfer lines starts to be the culprit. If you take shots at 2 or 3 minutes, this doesn't matter, but if you run a Canon on a StarTracker, with exposures measured in seconds, it becomes annoying. Try a little port-swapping, maybe plug in a hub. Or even disconnect your wireless keyboard/mouse or ethernet, strange tings can happen!

59 minutes ago, engstrom said:

I tried Kstars on my MacBook and on a Rpi 4b under Astroberry and they’re just not having it.

First I'd install the intended RaspberryPiOS on the Rpi4b (same as mine) and take it from there. You'll find all you need in the repo's. Then I'd take a closer look at the setup. The cables, quality of the cables themselves, any keyboard/mouse wireless dongle that may interfer, any wifi-dongle plugged straight in, and so on. One thing I know for sure, some of the Macbooks loose wifi if you hang on a wireless mouse. Weird. I always plug dongles like that into an extension cable, and get it out of the way. And the powersupply to the camera is VERY IMPORTANT. I had a problem with disconnects on my 5D MkII, and it turned out to be my 220V battery power adapter. Switched to a USB-type, no  problems at all, and now I can also use the fullframe on my StarTracker!

PS: Just finished the image from yesterday: http://www.agle.no/astro/vis_enkeltbilde.php?indeksnummer=109

Not state-of-the-art, but it never climbed over 25 degrees.

16 hours ago, engstrom said:

Do you find generally Kstars on a Pi using Canon cameras to be a MASSIVE P.I.T.A. or is it just me?

Not at all. Captured 140 frames, each 180sec on my Canon 600D last night. HEQ5 mount guided by a ASI120M in the finderscope of my 200PDS reflector. Smooth as silk. A RPi4 with 8gb ram and full desktop. Latest 64-bit Raspberry Pi OS. KStars and Ekos from the repo's. In order to get access to the ASI-driver, you have to engage the "contrib" and/or the "non-free" repo's.  Started with a trip to Capella. Capture-and-solve, check focus, then I pointed to LBN 647. New capture-and-solve, start guiding, and off I went. Started a run for 200 images, but clouds rolled in at 3 o'clock. Guiding was exellent, this target is very high above me.

I boot and run my Pi4 from a 250gb USB SSD with a seperate /home-partition. I run XFCE desktop with X11 display server. I have all the index-files I need for platesolving in my home directory on the SSD. With working wifi the Pi automatically picks up right day and time on boot. When I shut down and pull the roof back over my obsy, I just unplug the SSD and take it with me inside.

The Pi4 replaced a HP EliteDesk 800 this winter, mainly to be able to start up even if temperatures are well below zero. No moving parts. It's overclocked to 2200 and I keep an eye on things from my living room over the inbuildt VNC-server on the Pi. Works very well, but with 3 USB-ports taken by the rig and one for keyboard/mouse I need a hub in order to boot over SSD. I also need a port for an exteded USB-cable with a wifi-dongle outside the wall to get decent signal. I plug both cameras (and SSD) directly to the Pi and the EQMOD-usb, wifi and keyboard into the hub. Sometimes I open Stellarium or  browse the web while capturing, but things can get sluggish. Have seen this affect guiding, I don't think the inner "data highway" on the Pi is as wide as on the HP. Best to let it do it's things in peace.

PS: I also capture with a 450D (two in fact) and a 5D MkII. No problems.

8 hours ago, Adam Print said:

Does anyone have any opinions on the best option?

They are both 1200mm long. That makes the 10" f/5 while the 8" is f/6. The bigger one will not pull things closer. I have a 8" StelllaLyra dob for visual and a Skywatcher 200PDS (f/5) for AP. I also have a 6" f/4. The distortion near the edges increase as the f-ratio falls. In this case, the 8" will give a crisper view without correcting optics (reducers and such). If they both were f/6, I'd go for the biggest.

Why not use Siril? Can take multiple images in one take. Learn to use the "Convert" tab.

On 25/10/2020 at 20:38, Ouroboros said:

I’m worried about losing all my device settings and the files used for the plate solving. 

On the side; thread seems to stretch out: On Linux it's easy to back up personal settings, and take them from one install to another, or from computer to computer. Really handy regarding those big indexfiles for local platesolving. KStars uses this directory:

/home/<your_user_name>/.local/share/kstars  (dont miss the dot)

See if you find something similar om your mac (or even Windows) and keep a backup on a USB-stick. Or burn to DVD if you can.

5 minutes ago, jim waltman said:

How do you tell it what and where is the image to work on??????

Not sure on Windows, but on Linux Starnet++ is just a folder with the executable and some libraries. We put the image we want to work on into the folder, run Starnet, and move the original and the new imagefiles elsewhere afterwards.

2 hours ago, GrumpiusMaximus said:

However, if I'm hotspotting onto it, it won't pick up the time as there is no time server to reference

I see. Sounds like an akward setup. If I understand you right, you are VNC'ing into Astroberry while cut away from the rest of internet? And I think you confuse INDI and KStars/Ekos. The first is part of the second, but they are not one, and they are not the same. The INDI-server don't need to know the time, but KStars does. I use an OrangePi Zero 2 as a combined hotspot/INDI-server when I image with my StarTracker. Simple setup, just capture. What if you stick a beefy wifi-dongle into your laptop and connects to the berry with that? You can make a bridge via the inbuilt wifi adapter to a router with internet access. You also may experience dramatically better transfer speeds. Finally, I still means the best option is run KStars/Ekos indoors or on a device with proper storage. That is, something like my OPi-Zero. Wifi-hotspot and INDI-server only. But it requieres sensible transfer speeds. Good wifi. Always nice to get the subs straight on to a proper harddrive while  capturing.

7 hours ago, GrumpiusMaximus said:

Astroberry

Never gone the Astroberry route, always Debian or Ubuntu. I also do some remote, partly the reason I need wifi. When session is up and running I go inside, about 50m from my obsy. There I fire up X2go on my living room computer and hooks up to the obsy. A little sluggish over wifi, mostly to keep an eye on things and delete the odd bad sub. As for setting time; see if ntp is installed, or another service that uses the ntp (network time protocol) servers. On THIS machine, it's the "systemd-timesyncd" package. Internet connection requiered. If locale and timezone is set correct it should all work seemlessly.

Never considered a Pi3 B+ as a headless INDI-server on your rig, and a ethernet cable trough the living room window? There you can run KStars/Ekos on a decent linux laptop, and rule the world from your couch. The INDI-server is plain stupid, doesn't bother with time and such. Uses almost no menory and CPU.

As for setting up a Pi with KStars: Usually I partition my computers with their own /home, and starts up from a live-USB if the root partition goes sour. In this way I can recover my files, and maybe do a new root install without touching /home. Not so with the Pi's. You need to flash the whole card. And you can't use grub for booting. Don't know if you can boot from live media at all. Along with backing up your files, take a backup of /home/<username>/.local/share/kstars/  Here you find your astrometry index-files and all the settings. On a fresh install you often can dump these files in place and be up and runnning in no time. And transfer the settings between computers. Handy.

KStars and Ekos on a 8gb RPi4 with the "correct" accessories. It's replacing  a HP Deskpro 800 minicomputer. The HP  has served me well, but it has a mechanical harddrive that don't like to be fired up in sub-zero temperatures. My obsy has a heated computer room but I usually turn on the heat a few hours before I start. With the RPi4 I can turn on the power even if it's zero or colder. In the cold room I have an HEQ5 with a couple of reflectors and a bag of Canon DSLR's.  Guiding is done with a 120 mini on a SW finderscope.

The switch has not been painless, but in the end it seems to have paid off. Waiting for clear skies to give it first light. Besides running the rig I wanted a setup where I could browse the web and use Stellarium while capturing. The RPi4 is of the fattest, 8gb RAM, and it's "safely" overclocked to 2200. It runs 64-bit Debian Bookworm with Xfce from a 128gb SD-card with a 240gb external SSD for backup and file transfer. Stellarium is very fluid and Ekos hooks up perfectly, but there has been a couple of bumps on the road. First the lack of USB-ports. My rig only need three, and with my mouse/keyboard I thought I was good to go. Not. The EqMod-cable was so big it blocked one of the other ports. A USB3-hub solved the problem, but I'd rather do without. In the end I would need one nonetheless. It turned out the inbuilt wifi was to weak, and I had to hang on a dongle on a cable. Which I had to compile drivers for myself. With wifi sorted out it was time to test the SSD backup solution. The desktop randomly froze, and Stellarium became sluggish. This is something I've seen before.  I started out with a Logitech mouse/keyboard wireless combo, and once it was unplugged things straightened out. I could probably solved the issue with a long USB extension cable, but reached for my little red combo (with norwegian layout) instead. The Logitech wireless dongles have interfered with my computers on many occasions. If you have problems that cant be solved otherwise, try to unplug them, or get them out of the way (that is; as far away from anything else as possible). This time the problem didn't occur untill I connected the SSD. I also touched upon another issue; when I plugged the SSD into the hub, the wifi-dongle, which was also connected via the hub,  disconnected, but connected again after a few seconds. No big deal, but don't touch the hub while capturing if you have cameras and such plugged into it.

My initial plan was to use a RPi3 B+ as a standalone INDI-server on the rig, and link up over ethernet. Less cables, and no need for a hub. In the end I went for the direct connection. My three 5m long USB-cables has served me well for three seasons, and I like the simplicety.  

Nowadays it's all RPi5, but the four is pretty neat if you have a bit RAM and tinker with the config.txt in /boot. My testing so far has been limited to some random slewing, but everything seems smooth as silk. My initial plan was to replace the HP with an OrangePi5, I love them and have a spare, but I decided to give the RPi4 a try. So far, it looks good!

1 minute ago, Horwig said:

Could I interest you in a swap for constant cloud, nice and grey, no colour at all

No thanks. I'll keep the other "every second". Better than nothing.

7 minutes ago, GrumpiusMaximus said:

Apparently if they don't see the Northern lights at any point on their cruise, they get another half voyage for nothing

Chances are good that far north, as long as the sky is clear. Been a lot the last two-three  years. No chance to avoid it once it's there. If your first subs are green, you can just as well go to sleep, it will be there for the whole night, more or less. Even if it's not really spectacular to watch, very little is needed to spoil the imaging. On average, one in five nights have been spoiled for me during the last two years. And those have of course been sparkling cold nights with no moon.

2 hours ago, Horwig said:

Now I'd love to see one too

I's love to never see one again. Up here, central Norway, the aurora spoils every second night that's suited for imaging.....

On 31/10/2023 at 10:50, Elp said:

G'mic plugins

Go to "Repair" tab. Search for "Iain Noise Reduction 2019". Try these settings as a start:

Gamma   2  (right)          Shadows  1  (right)             Light   -1    (left)     Fine 0.5       Mid 0.15    Large 0

I'm shooting with a DSLR, and noise handling is a must. I havn't seen anything else that beats this plugin, once you know what settings to use. I do my noise reduction halfway through the stretch, that is after the "levels" but before the "curves". Do it as soon as possible, but you will need something to look at. Be careful not to make your image a plastic toy!!  Recently I've started to use the newly implemented Starnet++  in Siril.  When recomposing the image (putting the stars back) it seems to add a certain blur to the base image that even out some of the glossiness caused by noise reduction.

10 minutes ago, Mandy D said:

The learning curve is the problem, not really that GIMP is slow or difficult to use.

+1

Gimp has grown out from the Unix/Linux philosophy. It doesn't hold your hand, rather it expect you to know what your doing. With that said, it has an emormous community and help is never further away than a google-search. And Gimp is consistent. It is actively developed but has a strict set of rules regarding the graphical interface. To be honest, when I see tutorials for Photoshop I often wonder what their audience might be. The "hand-holding" is extensive, and the sheer number of scripts and plugins indicates a less capable user base. Everything boils down to maths and algorithms. Gimp can do everything that Photoshop and every other image editor can do, but you must know what you want to achieve, and how to do it.

12 hours ago, GeoAmy said:

best options for a total beginner to astrophotography

I bought a Canon EF 40mm F/2.8 STM AF Lens for my 5D MkII. Lens is good, but it has a huge drawback: You will have a hard time finding focus; the focus ring is electronically controlled and very difficult to handle. Very hard to finetune focus in manual mode. Go for a lens were the focus ring operates with the camera powered off.

52 minutes ago, Avocette said:

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.

I guess you are going to use https://downloads.raspberrypi.com/raspios_armhf/images/raspios_armhf-2023-10-10/2023-10-10-raspios-bookworm-armhf.img.xz or https://downloads.raspberrypi.com/raspios_arm64/images/raspios_arm64-2023-10-10/2023-10-10-raspios-bookworm-arm64.img.xz

When things are up and running, open Synaptic and search for KStars and the indi-drivers you need. Install from repo and try that out first. If things don't work out as expected, flash the sd-card once again and do it your way. Software from official repo's are not always the newest, but that should absolutely not be an issue in AP. You'd rather run software that's tested, and don't fall over during a session. And software in the debian repo's fits together and are updated when necessary. You just run "sudo apt update" and "sudo apt upgrade" and KStars/Ekos/INDI is updated together with everything else that needs updating at the moment.

11 hours ago, AstroKeith said:

Mine is a home grown Python suite of programs that drive Usb & serial connected peripherals

Well, sounds like you'll have to make your own repo!  One reason to use off-the-shelve software. In time the specs will mature and surface. Never tinkered on that level myself, can't really be of  any help. Good luck! Btw; why not use the indi-server framework as a backbone for your homegrown suite? The indi servers are not KStars/Ekos only, the API is out there. Extremely lean; i did a test on a RPi3 B+: The indi_canon_ccd peaked at 7% cpu during file transfer.

1 hour ago, AstroKeith said:

But if the package isnt in a repo?!

It is. Just checked. I'm writing this on a OrangePi5 on Armbian, based on Bookworm, and it's there. Can also confirm it's in the repo for stock Debian. At least what I need: indi-asi, indi-gphoto and indi-eqmod. If you need some rare indi-driver, try to find the deb other places, maybe download separately from Jasem's ppa.

If we are installing ordinairy software, we seldom use pip. It's for Python scripts and applications only. The prefered method is to install software from your distro's repo with apt. If you feel lucky you can try to find a package elsewhere in your native packaging format (.deb for Debian, Mint, Ubuntu, MX and more) for the version you use (Debian 12, Mint 20.04 and so on). Use dpkg to install downloaded .deb-files on your computer. If things go west (missing dependicies and such) use (sudo) "apt --fix-broken install" to clean up. If you use the native tools in the Debian universe it's hard to mess up an install. Not so on rpm-based distros. Or at least, it wasn't.  My first distro was Red Hat 7 in 2001. Those were the days.... Challenging, I would say.

Btw; Red Hat 7 from 2001 must not be confused with RHEL, Red Hat Enterprise Linux.

https://www.youtube.com/watch?v=iuMZG-SyDCU&list=PLrzbdmripj1c9p7hzt7ffgH3oN8vzCFI3&index=3

Start here. Then I suggest this one for the processing:

https://www.youtube.com/watch?v=4_a8XmC6H3I&list=PLrzbdmripj1c9p7hzt7ffgH3oN8vzCFI3&index=1

NebulaPhotos with Nico Carver and also AstroBackyard with Trevor Jones. Very good tutorials for the beginners.

8 hours ago, AstroKeith said:

For those brave, read up on virtual environments first and the relative differences between pip install, sudo pip install, apt get install and sudo apt get install!

pip is a python installer.  On bare-metal Debian you use "sudo apt install <myprogram>" to install software from the repo's.

On 17/11/2023 at 22:36, Avocette said:

I tried to use @Nou's script to install Kstars etc on RPi OS bookworm on an RPi 4 without success.

If RPi OS Bookworm is compatible with current Debian stable, Bookworm, you should not need any scripts. KStars, astrometry cataloges and most of the INDI--servers are all present in the repo's, both in armhf and arm64. Install everything with "sudo apt" or install Synaptic and use that.

Should be piece-of-cake. Not long ago you had to install Mint/Ubuntu and add Jasem's ppa, or build INDI-servers from source on Debian. Today most is present in the Debian stable repo's. If your Raspberry OS is Debian, based on Debian or otherwise compatible with Debian the KStars/Ekos/INDI-suite is just another piece of software, no need for witchcraft to get things running. Install Synaptic, search for KStars and indi and see what turns up.

I have an obsy with a heated section. I usually don't start the computer unless I have +12 celsius. Below that, my monitors flickr and die. Some are better than others, have replaced one monitor already. And then there are fans and oldfashion harddrives. The display temporarly dying is one thing, a corrupted drive is worse.