Rallemikken

And isn't it possible to work on 16-bit only? If so, you would half the space needed with just one config setting.

With my setup, Ekos clear calibration on every slew. So each time I start a session, Ekos does the whole calibration before guiding starts. Takes 1-2 minutes. And I let it settle for a few seconds more before I start the capture. Balance, weight, wind and other factors will vary. If I decide to do big changes during the cature, switch binning or go for single-star mode, I also do a new calibration. As for config, I can do a shot next time I fire it up. I don't correct for erros less than 0.4 arcsecond, and agressiveness lies between 0.4 and 0.8. I dither 3 pixels for every 5 subs, and always gives it at least 2 seconds delay before resuming guiding. The same goes when platesolving. Despite concrete floor and sturdy pier, my newt's need that time to settle. With good PA you shouldn't really need guiding, but it is handy on windy nights, it keeps the target within the frame, despite you have to toss some frames with elongated stars. And guiding opens the door to dithering. A bless for us with old DSLR's. PS: I keep my box at 16 pixels, as seen in the screenshot, and almost NEVER bin. And I have my guidescope pointing slightly away from the target. Not much, just a little, in my opinion it gives steadier guiding. Far from optomal to guide straight into the Rosette or Orion nebula. Or any star cluster. Should be obvious.

No. On that occation the focal lenght was actually 1000mm. In the dark I started the wrong profile... It platesolved OK, so I didn't do anything with it. This perticular part of the UI is the one I never look at. I think the guide RMS is calculated on the basis of the guide scope and camera, and that is the same, no matter what scope I attache on my mount. They all have the same findershoe, that fits the 50x180mm SkyWatcher finderspoe I use.

Not sure why. But my guiding is at it's worse when I shoot targets low on the horizon, with any wind attacking the scope from the side. If the wind had it's way, it would turn around the RA-axis. The DEC-axis is 90 degrees opposed, so much more stable.

If you do it manually, you can preprocess and register in batches. Not sure, but I think once you have the _r_pp-files the _pp-files can be deleted?? Once all are registred you must do some magic in order to gather all r_pp-files in one sequence-file before stacking the whole lot. I preprocess, register and stack files from different nights as a whole, with just one set of darks, flats and biases. And that is OLD calibration files. I have a feeling many overcomplicate the whole process. My darks have not changed in two years, my DSLR is pretty consistent. And I have one set flats for each camera/scope/reducer combo. No need to take new, I shoot with reflectors and naked sensors. As long as I keep the reducer clean on startup, I never experience those big donuts some struggle with.

No secret I'm a big Linux/KStars/Ekos fan. Tonight my rig started guiding with a total RMS of 0.11. The figures slowly increased, but never got higher than 0.42. The screenshot is taken halfway in a 3-hour run at Cassiopeia. The scope (Skywatcher 200PDS) is aimed into bortle 3 (I live on the border of 3 and 4) and is pointing almost straight up. And it's minus 12 degrees celsius, the grease in my HEQ5 is stiff and stable! The internal guider in Ekos have never let me down, but it's a savvy beast to master. I have a flimsy rig, a big newt on a medium mount, and only the finderscope in the findershoe to do the guiding, through a mini 120. I'm good when I'm below 0.6, but sometimes it's a struggle. I've learned a few lessons during my rather limited time in this game: 1: Have plenty of processor time and bandwidth for the signal from the guide camera. If the cursor, at any time, starts to drag, you are underpowered. Don't expect good guiding if you are low on cpu-cycles. 2: Curb the aggressiveness of the guide signal. In my case especially in RA. Usually i set it between 40 and 70%. This can be done "on the fly", just hit "Apply"! 3: Play with the time for each correction. Sometimes 2.5 second is best, other times I set it at 1 second. Can also be done on the fly. 4: Give the rig plenty of time to settle after dithering. I use 3 seconds. 5: Under really bad conditions I've found that manually picking a guide star and guiding in single-star mode gives the steadiest rig. Very rare, but try it once, just to learn the routine. When I do this, I pause the capture and restart the guiding.

It looks like these are for connecting non-standard lenses/scopes to the camera itself. You want the opposite.

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.

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.

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!

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.

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.

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 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.

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.

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.

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!

No thanks. I'll keep the other "every second". Better than 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.

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

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.

+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.

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.