I finally had the chance to acquire data to finish up some astrophotography projects. Specifically I needed Sulfur II data for an image of the California nebula. For this project I wanted to try a color mapping I have not tried before. I wanted to use Hydrogen Alpha in the red channel, mix Ha and SII data for the green channel, and use SII in the blue channel.
This took me 10 nights of data collection from home, since I can only image from 30° to 45° elevation, and it was great to finally get enough data to finalize the image:
The California Nebula in Perseus. I have tried to observe this target visually many times, but it has eluded me so far. Thankfully it is much easier to get a good image, especially with narrowband filters. This image is 2.5 hours of Ha data, and 5 hours of SII data. In the future I would like to try a mosaic to get the full nebula, with the same color scheme.
I also was at a very dark sky location (bortle 2), and got an image of the Dumbbell nebula (M 27). It was very windy, so I only got approximately 20 minutes of good RGB data, and 10 minutes of good luminance data. With little light pollution that data still resulted in an image I am quite happy with.
The Dumbbell nebula (Messier 27) in Vulpecula. I recommend opening the full version to really take in the full star field and the nebula. There seems to be more faint details around the nebula, so I hope to revisit this and get more and possibly longer exposures.
I have got several more projects in the works, hope to get them finished soon as well. Until then, clear skies!
Deep sky astroimaging season is over, and I finally have some time to process all the data I have captured. The first image I have processed is an image of a the star T Lyrae, which is a very red carbon star. Carbon stars look varying degrees of red due to carbon dust scattering light in the blue and green part of the spectrum. I became aware of these stars from an episode of the skywatcher webcast.
Imaging of stars usually do not produce very distinct images, they mostly look the same. T Lyrae has a very striking color though. I see the nicks Hidden Ruby of the Harp and The jewel in the Harp floating around the web. Quite fitting.
T Lyrae – Crop of 10x15s exposures using RGB filters on my Quattro 8″ using a Starizona nexus CC/Reducer and ASI1600MM Mono camera.
This star varies from magnitude 7.84 – 9.60 according to Stellarium (7.5 – 9.2 V says AAVSO) . This means it is not visible without aid, but it should be possible to see in binoculars, and it should be easy in my 10 inch dobson telescope.
I hope I get a chance to try to observe it visually this autumn, and I am planning to image more of these to make a small collection.
It is astroimaging season, and we have had several clear nights here. I finally worked out how to collimate my 8 inch newtonian well enough to use my Starizona Nexus coma corrector/reducer.
My Skywatcher 8″ Quattro together with the Nexus becomes an F3 system, which is a quite powerful little telescope. It requires very precise collimation and focus. This can be very challenging to achieve. I have struggled with it on and off for a year, and finally got it working fine.
I think these were the main issues. If you face something similar they are worth checking out.
Primary mirror clips were a bit too tight – Sometimes (I think this was temperature related) my stars would look oddly off. Once I made a bit more room for the primary mirror the star shapes became nice and round.
Secondary collimation with an badly collimated laser – I thought my Hotech laser collimator was well collimated based on rotating it in the focuser. Turns out it is very important to rotate and then fasten it to check the lasers collimation. It was not badly off, but enough to make it very hard to collimate at F3. I collimated the laser by repeatedly rotating and fastening it in a two inch eyepiece holder, marking the laser position each time. Then collimating towards the center, and repeating until the laser point is stationary when rotated.
Secondary collimation drifts a bit – The secondary collimation sometimes drifts a bit over time. It seems temperature related, but I am not sure why it happens. As long as I check before imaging it has been fine so far.
Pics or GTFO!
Once this was working I conveniently had the Rosette Nebula drifting by the balcony for a few hours two nights in a row. I imaged approximately 40 min of Ha, 80 min of OIII and 70 min of SII using respectively 120s, 300s and 180s exposures using my ASI1600MM camera, which resulted in these two images based on the same data.
The Rosette Nebula in SHO. Stacked using Astro Pixel Processor and stretch in Pixelmator Pro. It was not a very noisy image, but I did an ML denoise and a slight sharpen to deal with some noise at the edges. This version is slightly cropped due to rotated OIII images not aligning with the Ha and SII.
Same data with nearly no crop, doing a HSS coloring.
I like the SHO a bit more, but the HSS version looks really menacing and stormy. If I was a W40K artist, this is how I would depict a gate to the immaterium.
I think this setup fits the normal seeing here in western Norway a bit better then the basic F4 setup of this telescope. As mentioned it requires very precise collimation though, so you either need to be experienced or be prepared to use some time to get everything right.
I really hope I get some time at a nice dark site with this setup soon.
Should not have bought that drop bear repellent 🤯, better let him chew on some bits…
No drop bears or reMarkables were harmed making this post, but yours might be if you do nonsense like this. At least take a picture of the reMarkable ssh details before you startand proceed at your own risk.
I really like my reMarkable 2, but the default setup has some shortcomings. The cloud connect thing works nicely, but I want my backups in one place where I am in control. Currently that is my Synology.
My current setup is that my devices connect to the Synology using SSH keys. I do not want my Synology exposed to the world, so my devices are in a Wireguard network with the Synology. The setup of connections is managed using NetBird. To connect my reMarkable I would need to install a NetBird client on it, add a SSH key, then start using rsync to send files to the Synology. Should be easy…
Challege accepted! So began an adventure in cross compiling the tun module. Checking out reMarkable Linux got me the branch rm1xx_5.4.70_v1.3.x, which I eventually figured out was the latest release, and the correct branch for this.
Then I needed a cross compiling toolchain. Initially I got a wrong one, and builds would work, but tun would not install on the reMarkable with some really weird errors. Eventually I got the correct toolchain. It can be installed on Ubuntu doing:
sudo apt-get install gcc-arm-none-eabi
With the toolchain in order, Linux build configuration was the next hurdle. At first I struggled with full menuconfig, but a much easier way to configure Linux for the remarkable is to use the existing remarkable 2 (arch/arm/configs/zero-sugar_defconfig) config. I duplicated that and added CONFIG_TUN=m. Then did:
make ARCH=arm CROSS_COMPILE=arm-none-eabi- my-zero-sugar_defconfig
make ARCH=arm CROSS_COMPILE=arm-none-eabi- drivers/net/tun.ko
Got the tun.ko and smashed it into the kernel using:
cp tun.ko /lib/modules/5.4.70-v1.3.4-rm11x/kernel/drivers/net/
echo "kernel/drivers/net/tun.ko" >> /lib/modules/5.4.70-v1.3.4-rm11x/modules.dep
depmod
modprobe tun
And it worked! netbird status said connected!
Dropbear SSH
I added my existing backup key to the reMarkable, and got “SSH error something something”. SSH is also weird, I can not add -vvv to my SSH commands 🤯. ssh -v Dropbear SSH 🤯! I guess I should not have bought that drop bear repellent 25 years ago.
Dropbear SSH seems nice and lightweight. It really wants its own keyformat thing, so I used dropbearkey to generate a new key. Like this:
dropbearkey -f ./id_dropbear -t ed25519 -s 256
Added the printed public key to the Synology, and rsync finally works!
No cron on the reMarkable though; sigh; off to learn systemd timers…
Facebook is the only social network I use for anything serious. I wish it was more like the forums from 20-15 years ago, but I digress. Lately my Facebook got filled with more and more Suggested for you nonsense. Previously I used the hide feature on those, and that partly worked for a while, but now it just leads to more and more fringe stuff appearing. Eventually I conjured up some energy to deal with it.
What Stable diffusion should have come up with for the promt: Facebook Suggested for you on a good day.
I do not trust random browser plugins, so I decided to look into writing it myself. Firefox makes that very easy. This small snippet made Facebook acceptable again.
//Stupid flag to only run removal after some time, and not on each observed update
var mut = false;
//Get rid of "Suggested for you", probably needs customization everytime FB adds more divs ;) , worked on 19 Mar 2023!
function removeShit() {
if(mut == true) {
for (const span of document.querySelectorAll("span")) {
if (span.textContent.includes("Suggested for you")) {
console.log("Hide all the nonsense")
//The hardest part of all this is counting all that nesting, what is going on here.
var pr = span.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement
if(pr.style.display != "none") {
pr.style.display = "none";
}
}
}
} else {
//console.log("No crap seen yet")
}
}
//Observe the entire doc
const targetNode = document
//Observe all the crap
const config = { attributes: true, childList: true, subtree: true };
// Execute on observe
const callback = (mutationList, observer) => {
for (const mutation of mutationList) {
if (mutation.type === "childList") {
mut=true
} else if (mutation.type === "attributes") {
mut=true
}
}
};
const observer = new MutationObserver(callback);
// Start observing
observer.observe(targetNode, config);
//Interval to check for site changes and remove stuff.
const intervalID = setInterval(removeShit, 100);
As always, use at your own peril.
Facebook will still spice it all up with the ineffable timeline ordering, and still eats all the datas.
I love my reMarkable 2, it has worked great for all my needs with one exception. It was hard to use for mathematics, since it was hard to expand pages and have the context be preserved. I have been asking for this feature in all my feedback to reMarkable, and now it is finally available!
I tried it a bit last night, and it works great. I am really looking forward to try it more over Christmas!
After deciding to buy a proper equatorial mount (an SW EQ6-R Pro) with an astrograf , imaging has become much easier. I have also finally learned how to do collimation of mirrors well enough for it not to be a complete nightmare. It is still pretty nightmarish in the cold and dark, but what isn’t.
Guiding (using this camera in my finder scope to track stars) also has helped imaging a lot, since it partially compensates for polar align not being perfect, as well as allowing really long exposures if needed. From the city I do not see polaris, so I just do a very rough polar align and hope guiding deals with the tracking issues. I should probably learn to improve polar align based on mount tracking errors, but it seems like such tedious procedure. I have yet to find the energy to learn it.
The quality curse
One nice thing about lucky imaging DSOs is that most non tracking related image defects are not really a problem, since they are swamped by tracking issues. I was super happy if I got halfway decent data. Now with proper tracking I get really annoyed by tiny technical defects.
Anyway here are my best images from this year so far. I had a lot of fun taking these and editing them. They are all taken with only dark calibration frames, and either using fake flats or no flats. AstroPixelProcessor is magic, all the DSO images are stacked partly post processed using it.
The images
M31 – Andromeda galaxy, as well as M110 and M32. Approximately 2 hours of 180s exposures at 1600 ISO.M42 – The Orion nebula. I think I managed to nicely balance the very bright core and the rest of the nebula. A mix of 30s and 60s exposures at 800 ISO. In total 1 hour of exposure. Then some creative editing to keep some detail in the core.Moon, with increased colors saturation to show the different shades of gray reflected. This is 130 images stacked, from a series of 1000 images. It was stacked using PlanetarySystemStacker, which is very neat for us Mac users who otherwise do not really have any great native stacking applications for planetary images.M45 – Pleiades. This was a hard edit since it was taken from bortle 6 skies with no filters or anything. UGC 2838 is also visible in the upper right part of the image. That is one pretty faint galaxy!
I am bitten so hard by this hobby so expect more astrophotography related content. I will try and post other stuff as well, but this is way too much fun.
Something that feels like a once in a lifetime event happened here in Bergen this spring. We had four consecutive days of clear skies, with very little wind and no moon!
Earlier on the blog I have expressed the desire to try and image Messier 13 on consecutive nights, to see if I could see the difference in magnitude in the variable stars in the cluster. Especially the variable star V1553 Her, which has a very convenient period of approximately 5 days. 4 days of observing would get me most of the period.
These 4 days were pretty late in spring (30th of March to 2nd or April), and observing had to be done after 10PM in a work week. Not ideal. Thankfully except from the usual tracking problems, there were few problems with the equipment. My own patience failed while doing focusing though, which resulted in two nights with good images, and two with not so great quality.
This was a bit problematic since I wanted to compare images over time, and since I had 40 good images from one night, and 10 from another there was a big difference in the brightness of the stars once I was done stacking images from each night. To account for this I did some brightness matching in post processing matching on the non variable stars of each frame.
The resulting 4 frame time-lapse looks like this.
I was pretty happy with this, as it shows the variability of not only one, but at least one more, and maybe even a third variable star I missed at first (Can you find it? This paper has charts to help). The change in brightness especially for V1553 Her was also much clearer then I expected. Great success!
The process to find the distance to the star from the magnitude and variability data is neat. Since V1553 Her is a Type II Cepheid (how this was determined is not clear to me, please add a comment if you know) which period is approximately 5 days the star has an absolute magnitude of approximately -1.5 according to this chart. The formula below (from here), should then give the distance \(d\).
$$ M_v = m – 2.5log((d/10)^2) $$
Looking at the images and the reference stars, a rough estimate would be that V1553 Her varies between 12 and 13 in apparent magnitude. Plugging in -1.5 for \(M_v\) and 12.5 for \(m\) gives the distance of 6310 parsecs, which is 500 parsecs off.
While I have not followed a very thorough process here, it is anyway nice to verify that my data seems to fit to reality. To get better data for deep space objects, I am evaluating to get a solid equatorial mount with either a small refractor or an 8 inch newtonian for imaging, and keep my dobsonian for visual and planetary. Once I do I hope a can revisit this project and get a time-lapse with much higher quality. Maybe do one which would also capture the really fast variables with down to 0.2 days period.
I have been hacking on some libcamera experiment, and this time I had the misfortune to have to try and use a Jetbrains product in a local VM and on the host system at the same time.
Since it is practical I was using UTM shared networking, but that had the unfortunate side effect that Clion in the VM and IntelliJ on the host detected each other and refused to both be open at the same time. Incredibly annoying…
Googling I figured out that if you use the same username in the VM and on the host it will all work out. I got more and more confused as to why this feature exists, but a glimmer of hope emerged. I was not ready to change user in the VM or on the host though, since I had used some time to set up that user.
Thankfully, this detection feature uses the JVM system property user.name, to lookup the user, so adding -Duser.name=<host username> to the clion64.vmoptions file made it all work out.
I love observing globular clusters visually. There is something very satisfying about turning the focuser to try to resolve the maximum amount of stars.
On the 12th of march I did an observing session in moonlight and quite a bit of wind, and I finally learned why astrophotographers dread wind. The telescope kept shaking, and had to park my car in front of the telescope to get it to be usable at all.
That had the sad effect of blocking most of the sky I was interested in, but M3 and M13 were still visible. After doing some visual observing I did some very lucky imaging in the wind. Of about 350 exposures of M13, about 70 were decent, and 10 of those were good. Stacking those 10 gave me this image.
M13 (Hercules Globular Cluster), image using my 10″ skywatcher dobsonian, a Televue powermate 2x, and my Canon EOS RP. This is 10 exposures of 8 seconds at 12800 ISO, stacked using APP.
