Here's another take on the Saturn at opposition, year 2021 image. It's from the same raw data as the image in my last post, but this time with more aggressive Registax wavelet sharpening. I think I like this one better.
I've also inserted a thumbnail, if you prefer to view the image that way.
As long as I'm posting, let me relate the hardware troubles I've had lately, and add a little commentary about lucky imaging techniques.
I'll start with the "lucky imaging." Lucky imaging takes a stupid amount of data. And by "stupid," I don't mean dumb. I mean "mind numbing," as in lucky imaging takes a mind numbing, ridiculous, unholy, stupid amount of hard-drive space.
The idea behind lucky imaging is to gather data as fast as humanly possible (well, as fast as the camera and computer combination is capable of gathering it). Then later when processing, ignore some of the "bad" frames -- maybe half of the total -- and still have enough left over for the central limit theorem to do its thing when warping and stacking. And you'll find that some runs are simply better than others due to general atmospheric seeing conditions. So you'll want to take many runs, and then choose the best run.
As an example, for this Saturn image I imaged over two nights, taking between 5 and 7, 36 minute runs per night. I averaged over a terabyte of hard-drive space per night. All that data has to be processed, at least a little bit, in order to determine which runs are better than the other runs. But even after weeding out the bad runs, it still means that a given image starts out as hundreds of
megabytes gigabytes of raw data.
It also means that if you're imaging multiple nights in a row, you need to get that data off the laptop's hard-drive (technically an SSD) from the first night, in order to make room for the second night, because that drive
will fill up. Realize that you don't necessarily have the option to space out your imaging sessions, because the planets and the weather won't wait. Sometimes that data needs to be processed, or at least transferred, immediately.
And processing the data isn't instant. AtuoStakkert! is a great program, but it takes a while. It's good to have a fast desktop computer, if you can.
Getting back to my story, after packing up after the first night of imaging, I immediately plugged a hard-wired ethernet cable into my laptop to start transferring some of that data over to Clubber Lang (my main desktop computer). But it was taking a long time. Like a really long time. The transfer speeds were like one tenth the speed of even a wireless connection, and here my network equipment is wired and
Gigabit speed capable. What the hell?
I spent much of that night and the next day (during daylight hours), processing as much as a could on the laptop (which wasn't that much), deleting the raw data once processed, and using a 256 GB USB flash drive to transfer the rest of the data to Clubber Lang. But remember: stupid amount of data. Each run took hours to write to the USB flash drive, and another 45 minutes for Clubber Lang to read it. A Stupid, unholy, godforsaken amount of data. I had to swap the USB drive back and forth about a good half-dozen times. And that coming night was the only decent weather forecast for the foreseeable future, so that data had to get off the laptop one way or another.
So I finally got the data off my laptop by evening, and fired up the telescope for the next night of imaging. But the telescope was frozen, and wouldn't respond to the hand controller key-presses. I suppose I could do all the control from the laptop, since that was connected to the telescope anyway, but I'm old-school like that and like to use the hand-controller. About a year ago, I noticed the hand-controller's cable was becoming a bit frayed, and I fortunately thought ahead and scrounged up a new RJ11 cord and kept it handy, just in case. That did the trick, thank goodness. (If you look at the picture of my telescope a few posts ago, you can see the old hand-controller cable on the table, to the lower right, behind the laptop.)
Then the telescope wouldn't acquire a GPS fix. I still don't know if that problem is temporary or permanent. It's not a showstopper though; I just punched in the time and my location manually. From there I was able to finish out the second night of imaging (the image of Saturn in this post is from that night).
----------------
Then comes the network debugging. Running some speed tests, I was able to narrow down the culprit to my desktop computer, Clubber Lang (the laptop and router were fine). The weird thing was, the hardware LEDs and even the drivers indicate that the network is working perfectly and at Gigabit speeds, and yet Clubber Lang's actual network speed is slow as molasses in January. As a debugging step, I also switched over to WiFi, and even the WiFi was slow. That lead me to the conclusion that it wasn't a bad connection, but rather something above the physical layer.
But both the WiFi and the Ethernet are controlled by the Intel Z390 chipset on the motherboard. Maybe that was it. I reinstalled the driver from my motherboard manufacturer (ASUS). No change. I installed another version of the driver directly from Intel. No change. I got on Amazon and rush-ordered a PCIe Network card because I was losing faith in the motherboard's networking capability.
I remembered I had a USB WiFi dongle that I was using for another computer. So I grabbed that and plugged it into Clubber Lang, heard the Windows USB enumeration tone, but then decided I should plug it into a different USB port and did so. But this time no Windows USB enumeration tone. Did I unplug the dongle when it was writing to its internal storage? Did I zap it some sort of electrostatic discharge? It's not clear. All I know for sure is I bricked the USB dongle then and there. 'Just my luck. That debugging step would have to wait until the new network card arrived.
A couple of months ago Clubber Lang had an SSD failure. I didn't lose any important data, but I did have to do a fresh install of Windows 10. Maybe that had something to do with it, and I just haven't noticed the slow network until now (The network still worked, it was just slow). But I had already gone through Windows 10 network settings with a fine-toothed comb, and didn't see anything suspicious. But I figured I should re-install Windows 10 again, and see if that helps. So I did, (keeping my apps and files though). Still no change.
A couple days later the PCIe network card arrived, so I installed that. Once again, no change. Even with the new network card, everything was still slow. So the problem had to be either Windows or something running on top of Windows.
So I went through every program that I installed (recall I had to reinstall everything a couple of months ago) and came across a program called "GameFirst V" It's a program that ASUS packages with it's motherboard, right along side the chipset driver and motherboard tools. I had installed it a couple months ago, when doing the fresh Windows 10 install, without giving it any thought. After a little research I found it has something to do with networking, so I uninstalled it and Voila! Glory be, my network was fast again!
But good god, ASUS, really?! Apparently the sole purpose of this program is to cripple the networking capability of any non-gaming application that runs on the computer, even if you're not gaming. And that's its default behavior. And when installed, the program starts automatically on startup. Are you freaking kidding me?! Gaaah! I'm pulling my hair out as I write this.
So if you've read this far, and you're looking for some sort of moral to the story, it's to be careful what programs you install, even if they come with your motherboard.
(Oh, I forgot to mention, a Display Port cable is on the fritz too. I ordered a new one along with the PCIe network card.)
Summary of recent casualties:
- 2 TB NVMe SSD
- Telescope's hand-controller cord
- Telescope's GPS functionality (maybe; this is still uncertain.)
- USB WiFi dongle
- Display Port cable
- My sanity
- Hair
Newfound benefits:
- I now have a spare network adapter card, just in case.