Rallemikken

Boiles down to philosophy, I want real colors, and I won't let anything tamper with it on it's way to the sensor. And the days around full moon means rest and restitution. Long nights this far north, I know from experience there will be plenty of integration time this winter too!

Hope so. Must learn to tune it. And the smaller sensor size (for me that are used to old Canon's) means that I don't have to bother to much about what happens near the edges. The fullframe 5D can be demanding. As for filters, don't use them. Bortle 3/4. I'm also hesitant to use any glass between the mirrors and the sensor. I also have two newt's, one f/4 and one f/5. The f/4 must have a flattener, with the f/5 it depends on the target. How much I can crop out.

Hesitated to do that, would not resample. Now I see that SGL HAS RESAMPLED AND SCALED, so the whole post has been in vain. But I see your point. Some makes an big issue of pixelscale. The IMX294 has pretty big pixels, 4,63um, but the 5D has even bigger pixels at 6,41um. A scaling would show if there are some truth in this. I got the 8" RC (1600mm focal length) and the IMX294 for use on galaxies and small, but not to dim targets. Season has just started for me, looking forward to test it some more.

Full moon, not much you can do. Did a small comparison; 5 frames with my new IMX294, and 5 more with my trusted Canon 5D. Not super-impressed by the new kid in town. Top: Canon 5D MkII, 120 seconds, ISO 800. Stacked with 5 calibration frames of each, color calibrated and a pretty hard stretch. Bottom: Touptek IMX294, cooled to -10C, 120 seconds, gain 398, offset 100. Stacked with 5 calibration frames of each, color calibrated and a pretty hard stretch. Scope: 8" RC, target M82. Blindingly bright and full moon, but no moonlight into the tube. No skies. 10 degrees celsius, that means the Canon had a big disandvantage, as I turned on the cooling on the Touptek. Not sure what to expect. Stacked and photometric color calibrated in Siril. Both images are stretched with levels in Gimp until the histogram looked similar. Pixelscale 1:1, only crop, no resampling. The IMX294 has smaller pixels and brings the galaxy closer. That means that the targets brings more light into the frame, and the background gets darker as long as I insist on identical histogram peaks. M82 will be my next target with this scope when conditions permit, not sure what camera to use after this.

As you should do. On Debian-based systems there are four main types of installing packages: 1: From the distro's main repos. The recommended way. Sometimes you have to engage parts of the repo in /apt/sources.list or files in /apt/sources.list/d due to non-free software or software with binary blobs. This is the case with the indi-asi-driver in Debian stable. Neverthelsess, what you install in this way works 100% in 98% of the cases. Tested and trusted. 2: From repos you add yourself. You add a line in /etc/apt/sources.list or a file in /etc/apt/sources.list/d. Often done in order to use stellarmate's repo onto Debian-based systems. If the external repo is based on the same distro, this also works well most of the time. In the example of stellarmate, the newest version is compiled against Debian Bullseye. This means that if you use this on an original RaspiOS for RPi5 you might face problems, it's based on Bookworm, but it's worth a try. If it doesn't work, you just uninstall and remove the access to the repo. 3: From PPA's. This works only on Ubuntu-based systems (which in turn are based on Debian). Jasem Mutlaq's PPA for KStars and INDI is a good example. This works well in most cases, but as the Ubuntu family widens out this approach is starting to crack up. If you stick to Ubuntu, you'r good, but if you use Mint, Armbian or another member of this family you might face problems. Two or three drivers can work well, but if just one crashes you're out. Also a safe way, you can always uninstall and your system is pristine again. The PPA can be unhinged. 4: From source. This is the most complicated way, and you have to know what you are doing. You can make your install unbootable. Been there, done that. There are plenty of scripts to help you in this endevour, but it doesn't take much effort to learn the basics. The guide on https://github.com/indilib/indi-3rdparty is very good and holds your hand on the way. Take one command at a time, learn what it does. Read error messages, use google, and keep on until everything is in place. Number 1 and 4 should give you stable and solid installs. Recently, especially on arm-based hardware, I've had problems with all four methods. You should troubleshoot any driver that causes problem BEFORE you wipe or reinstall. Just a few commands can give insight in what's happening. Sometimes it's just a small detail. * Open the directory /usr/share/indi Here there are .xml-files for different hardware groups. Open the one that matches the defect driver, i.e. indi_asi.xml in a text editor. * Look for the right hardware and the driver assignment, i.e. indi_asi_ccd if you have just one ASI-camera and it causes problems. * Start your computer, don't touch any software. Turn on the device (camera), and open a terminal. * Type in this: indiserver -vvv indi_asi_ccd No sudo, and replace the name of the server in question. * Read the output. See if anything means sense. Terminate with Control + C * If you run a remote indiserver, SSH into it and pull the same commands. The directory structure should be the same, unless you are using something really special. If you get a message that says something like "bind: Address already in use -- good bye" the server is already running. Stop it with killall indiserver and start it from fresh.

If you are building from source, you don't add Jasem's repo??? AFAIK ppa's are not supported in Debian and Debian-based distro's. Maybe I'm wrong and things have changed, but ppa's used to be for Ubuntu and Ubuntubased distros. Like Mint. Raspios is based on debian. That said, all distro's based on Debian 12 Bookworm HAS THE MOST COMMON INDI-DRIVERS IN THEIR REPO's ALREADY! INCUDING THE ONES FOR ASI! You just have to add 'contrib and 'non-free'. Some are missing and have to be buildt from source, mainly the ToupTek-derived cameras. Armbian has images for RPi5 based on Ubuntu Jammy (22.04 LTS). https://fi.mirror.armbian.de/archive/rpi5b/archive/ With these images you just add Jasem's repo and install as usual. No building from source. But be aware: I've had mixed experiences with this approach. Jasem's repo is in many ways a moving target. On a bad day you can have driver chrashes and connection problems. Not nnecessary the repo's fault, more the fact that the family of these distro's starts to get big, and the variations between them starts to show. The ONLY distro based on Jammy that gives me consistent installs is Bodhi 7. Mint 20 and 21 has been my daily drivers for years, but lately I've had trouble with both my EQMOD and TOUPCAM drivers on Mint 21.3.

This is what I get when I overdo the "Asinh" function in Siril. Always start with that. Got my own way. Incremental. Start with i.e. 6, then 5 and so on down to 2.

I've actually got an image of the season's first star, it happened to be Vega! Two days into what ClearOutside calls "Civil darkness" I was out at midnight and did my first run. I actually got the rig to guide! I live at 64 degrees up in Norway, and I can't do any decent AP until mid-september. During the closure of last season I've spent some bucks on a new 8" RC and an IMX294 color camera. When the first fits rolled inn, I was cocooned in a warm, fuzzy feeling, the star had well defined spikes from edge to egde, and those visible in the corners were round and even. Fingers crossed, may the next five weeks go by in a flash!

If it's never been out, it most likely points straight down. But look for adjustment screws between the focuser's base and the focuser itself in case it's divided in two parts. Anyway, if it's not straight and no adjustment possible you can correct any error with spacers. Maybe not relevant here, but when you are collimating a newtonian for imaging, the direction of the focuser is where you start if you suspect something is wrong. It's one of those things you do only once, or each time you have it out.

Start with the focuser itself. If someone has taken it out, perhaps during flocking, it's a chance that it's not aligned right. Best way to check is by taking out the spider, and use a cheshire (or laser), and see if the line of sight is 90 degrees to the main tube, and no sideways tilt. Use a ruler and a permanent marker. If the secondary is slightly high or low does not matter, as long as the scope as a whole is collimated and the usable lightbeam from the primary dont reach the edge of the secondary. But if the drawtude/focuser is misaligned, it will cause severe artefacts on the stars that you don't expect from even a little error.

I'll attach my settings, for both INDI and Ekos. Maybe someone can benefit from them. I use an ASI 120MM, same pixel size as yours, but 1,2mp contra your 2.3mp. And yours are color. Both are 12bit native. As you can see, INDI treats mine in RAW 16bit. Don't ask me how. I never bin, and use box sizes of 8 or 16 pixels. Once running, it reports between 50 and 100 stars available. Most settings are visible in these images. I think it is crucial to have an almost black image, with enough stars clearly visible as sharp points. Turn your guide camera to your imaging camera for a while, and toogle the settings until you get frames that looks good for this purpose, and use that as a base? I did this tonight, and the fits viewer reported 1 sec exposure time, 32 in gain and zero offset, as in the settings. Maybe I could increase the gain, and get shorter exposures. Could be beneficial if I guide on shorter intervals, but "if it ain't broken, don't fix it". And I don't think Ekos waits until the last image is processed before it initiates the next. As you can see, I have the 'Delay' settings at zero. Never happened that the guide frame have had oblong stars. But if the exposure time is near or the same as the interval, this must be set in some way. No expert, in any way, but I have run KStars/Ekos/INDI on many configurations and on different hardware. Learned two or three things: If you update, clone your SSD and tuck away the backup. And do it before the season. And on the Ekos side, CPU cycles are king, especially when it comes to guiding. It is the first thing that starts to suffer. And last, if you run a headless INDI server, you can do with a RPi3 B+ as long as you use USB2, as I have done until now (ASI 120MM and Canon DSLR's) but you can NOT rely on wifi. Not even on a Rpi4 or 5. Take the trouble of stretching a network cable, it will save you a lot of grief. I use a INDI headless server and wifi when I start up my StarTracker, but that's without guiding, the worst that can happen is that the images takes a little long to reach my laptop.

Rebellious. Quote myself. I recon PHD2 choose it's own gain and exposure settings for the guide camera, as long as it handles it on its own. Have you looked into the tab for the guide camera in the INDI control panel? This is where these settings are set on the guide camera in Ekos. I don't think you find them elsewhere.

The right way, btw. To many run the whole Ekos suite on to small hardware. I used PHD2 with Ekos in the beginning, long time ago, can't really be of any help. When Ekos offered multistar guiding I left PHD2. The internal guider didn't do a worse job then PHD2, can't claim it is better when I don't use PHD2 anymore. If I understand the Ekos/PHD2 combo right; you just start the PHD2 application and do the rest in the Ekos interface? So, all options regarding binning, exposure inetrval, settling time and so on should be the same, regardless of what does the guiding? The only difference is that PHD2 grabs the image from the guide camera, does the calculations according to your settings, and correct the mount? Ekos own guider is fully capable of guiding well under 0.4 RMS. I have had run over 4 hours without exeeding that value once. So it can do the maths. The culprit must be either how the guider (Ekos or PHD2) aquire and handle the image from the guide camera, or how it respond to the mount. The options in the 'Guiding' tab in Ekos are many and not so obvious. It is easy to mess up, but once you are on track you hardly need to adjust anything. The only option I touch from time to time is the exposure interval. Never below 1.5sec and never more than 2.5sec. I can start my obsy and take a few screenshots of these settings that have served me well the last three years, but I can't do any guiding. Not dark enough, and cloudy.

I don't have LP, lucky me! But I'll build my library of darks and flats while I wait for the season to start. As soon as the stars show up, I'll report back.

They don't. At least not "Dazzling Photoelectric Store". But I was prepared for this. I bought a IMX 294 color ToupTek from them, delivered to Norway. The key is to not pay VAT twice. I had to pay 25% norwegian VAT pluss a small fee on arrival. Everything seemed OK, and still do. Works both on Windoze and Linux. The camera was very incognito, no markings at all. When connecting to Windoze it presented itself both as RisingCam and Touptek. Under Linux/KStars/Ekos/INDI it showed up as Toupcam.The reason I choose this rather esoteric store was their claim of "zero Ampglove". Not that important, but it showed up to be true. I know there are at least two versions of these cams, and I wanted to get the latest. The inbuildt dew heater is accesible in the INDI-driver, this was the one thing thing I feared was missing. Can't give any review untill mid-september, that's when my season starts. But technically the camera seems OK.

Two hours total on that target with a Canon DSLR is not enough anyway. Seems slike a rather short scope. Those colors in the background is typical if you stretch the image too hard. In the strive to fish out details and colors in the target, you also raise the saturation of the background. Takes some experience to handle. That's why you NEVER should toss away the dataset; trust me; in a couple of years you will do a new stack. Maybe with more data, remember to use the exact same setup. As mentioned, start dithering. And make some rules; I never stack datasets with less than 5 hours exposure, or less than 100 good subs (after the deletion of the obvious bad ones). And make a library of darks. The old Canon's have lots of hot pixels, shoot 20-30 of each exposure time + ISO combo. Mayby one for cold and another for warm weather if it vary much, but that is really not so critical. I often blend subs with different exposure time and ISO settings when I stack in Siril, using only one set of darks. Works well, as long as you pay attention to what to include in the final stack.

After I replaced the hardrive with a SSD, I got an issue with my HEQ5. It wasn't detected at boot. I think this is due to how things are detected and negotiated at startup, things just go to fast for everything to be picked up. I resolve this by just unplugging and plugging back the USB-cable when things are settled. Annoying, but no big deal. And I also always switch my mount on BEFORE firing up my computer. Same goes for cameras.

I have never used other than the buildt-in plate solver in Ekos. KStars depends on libstellarsolver. From the package description: "libstellarsolver - StellarSolver Library - This package includes an Astrometric Plate Solver for Mac, Linux, and Windows, built on Astrometry.net and SEP." It pulls in the index files you need from Astromony.net. Check the 'Preferances' button under the PA/Solver tab. They can also be installed permanent as deb's on each install, but I prefer to have them in my home directory. They are huge downloads, and when I keep them in my home directory I can transfer them easily between machines. The PA routine in Ekos is a bit chunky. I use the same exposure time here as when I plate solve, but I pick my oldest DSLR with the fewest MP (my trusted old Canon 450D). And be aware of movement. Star trailing. Take your time between each adjustment. I have a pier, and use this routine only once a year. To lenghty and cumbersome to do if you tear down the rig each night. The good old visual polarscope way is superfast and accurate enought on my HEQ5. I belive the INDI driver was 'SynScan Legacy' when I used the USB-port in the handcontroller.

I use a 5M 'EQDirRJ45 EQDir' cable, works fine, but not without niggles. On some setups I have to unplug and plug to get it recognized. No big deal. Have run Ekos with a USB-cable into the handcontroller, but it sometimes messed up time and place. Pointed the scope allover the place. If the mount works in other aspects in Ekos, in should not be the culprit regarding guiding. When I start a session, I give the scope order to slew to target. Then I platesolve (with the buildt-in solver) and ticks the option "Slew to target". After 2 or 3 pictures, I'm always on. Also handy when doing initial focusing. Platesolve onto a bright star. If this works, then guiding should also work, as for the mount . At least with the native Ekos guider.

You don't say if it is under Windows or Linux. Anyway, there are a couple of things i'd like to mention. I have run KStars/Ekos/INDI on Linux for many seasons now, but as most I started with PHD2 and various software for capture. 1: Try the native guider in Ekos. In the default configuration (or at least mine) it calibrates itself before every capture sequenze. Takes a couple of minutes. I never reuses calibration data. Calibration will vary, depending on angle of dec/ra. Always start with a fresh calibration with the scope pointing at the target. 2: Don't think there is such a thing as a "guide" or "guiding" driver. For things to work you need the correct drivers for the guide camera and the mount. And those are INDI drivers. Never heard of anyone using ASCOM in the KStars/Ekos suite, but I can be wrong. The EQ5 can use different drivers, depending on how you hook it up. 3: Once everything is up and running, time to tweak the settings on the guiding. Guiding can be taxing on the USB-bus. If you arn't satisfied, try another USB port, sometimes ports shares lanes inside the computer. And use a computer with good specs. If you guide on intervals under a second, you must have some cpu-time to capture, transfer, process and correct, all in good time for the next. I never go under 1.5 second. Most often I use 2. In my experience, computers such as the Raspberry Pi 4 isn't up to the task. When things start to kneel, guiding is the first that will suffer. I use an old HP EliteDesk 800 with 8gb RAM and a SSD. Most often I guide below 0.5, a little depending on where I'm pointing.

Yes, and we can think a little more about composition; framing a bigger piece. I did a picture of Navi last winter, with the star a bit right and above of center. IC63 came in from underneath and left, and IC59 sideways on the same side a bit above. A gem! Far from my technically best image last winter, but it made it to top three and earned a frame in my living room. I like buzy regions around big stars with long spikes! Drama and beauty, but sometimes hard to handle......

Spot on! Some are small and very faint, though.... Found some data here: https://heasarc.gsfc.nasa.gov/db-perl/W3Browse/w3table.pl?tablehead=name%3Dhcg&Action=More+Options Have made a spreadsheet, will stitch it up in my obsy!! The biggest should be plain sailing, even with my 8" newt. Based on dec and angular size, at least 15 should be in reach. We'll see where the journey takes me!

Last year I stumbled upon a "targets-todo-list" here, and it kept me occupied for many nights. It was a list over odd and rare targets that seldom or never is mentioned. Along the way I learned a lot, about imaging, physics, the astromoners behind and life in general. With an 8" reflector and a Canon DSLR I was able to get decent images of all, but one. "The Galactic Wanderer", NGC 2419, was one of those, with a few peculiarities and a story to back it up. It was a target I could spend time on between the clouds while I was waiting for true clear skies. As weeks went by, I did the whole list with a few exeptions due to latitude. I'm starting my fourth season this autumn, and I'd like to broaden my horizon. Any suggestions? Hopefully something I can try with pretty basic equipment? I'm also looking for pure beauty, small patches of sky that stands out without any Messier or NGC- number ????

I'm a Linux guy, and use Siril and Gimp only. As Pixinsight is developed under Linux, I should feel at home. I'll download the trial later this summer. I use StarNet++ in Siril, but can't get the starmask as I would like it. I can have well defined spikes and small stars, but not bright and shiny at the same time. If I want bright stars they get fat, and the spikes becomes diamonds... Have to work on that a bit more. Maybe Pixinsight will be the right choice.

That's impressive! We're talking 1.2 MP here. How would this look without BlurXtermiinator? I've been fiddling with Siril and Gimp an hour by now, not even close! Especially the stars, can't get them that well defined. And those spikes; love it!