wimvb

I installed xrdp and use windows remote desktop. I never got to grips with nor really liked vnc. Rdp is also available for mac and android, although using it on a tablet without a proper keyboard or mouse is a pain. I only use it on my tablet when I need to polar align at the start of astro season, so I can have a screen close by.

The difference between thin and thick vanes is most visible int the way colours are diffracted. Also, thick vanes block more light than thin vanes.

Indi device drivers depend on each other. Somewhere in the documentation there is mention of needing at least two devices: a camera and a telescope/mount. (Without a telescope, the camera can't know fov or pixel scale.) But either of these can be a simulator device. To test a new camera, you connect it to the computer, and create a profile with its driver plus the telescope simulator. You then configure the telescope simulator to match your real telescope (fl and aperture mainly)

I don't use astroberry as my sbc is a Rock64, but I learned to never upgrade during astro season. When I started using INDI/Kstars, new upgrades could be so buggy that I would lose several precious imaging nights. Hence my policy to upgrade only during summer recess. Nowadays I have several sbc's and only upgrade one at a time. That way, if something breaks during an upgrade, I can just swap computer and keep on imaging. It's better to have an older version that works, than the newest gadgets that don't.

No, I just added the repository and installed indi/kstars

I agree with @Dr_Ju_ju, installing on Ubuntu/Armbian, should be as easy as adding the repository and installing with aptitude. sudo apt-add-repository ppa:mutlaqja/ppa sudo apt update sudo apt install indi-full kstars-bleeding gsc Addendum: I'm posting this from my RockPro64, which I connect to via RDP. I just updated indi and kstars by just using the last two commands in the above list. The sbc now runs Kstars 3.5.3. I have my gear in summer storage, so can't test it with hardware, but the Ekos simulators work just fine.

I have been running INDI/Kstars on a Rock64 (Rockchip RK3328) for several years, and also have a RockPro64 (Rockchip RK3399). Because the RockPro64 is larger, I haven't mounted it on my telescope yet. (I bought it because it uses 12V instead of 5V, so one less cable.) I use Armbian as OS, and have the stable pre-compiled version of INDI/Kstars installed, which runs without any issues. I think I must have been one of the earliest users of 64 bit systems, because I had to ask the developer of linux phd2 to add 64 bit to the repository. Anyhow, early problems were mostly related to instabilities in the OS, and (un-)availability of 64 bit software. I used to have Ubuntu/Mate installed, but switched to Armbian a little more than a year ago, and haven't had a problem since.

I dug up my copy of Maskulator and calculated the diffraction for thin single spider vanes, thick single spider vanes and thin double spider vanes (separated the width of the single thick vanes). 1. thin single 2. thick single 3. thin double (click on each image to get the full resolution, 1024x1024 pixels) This is highly unscientific, but it seems to me that the double vanes have stronger diffraction spikes. This is to be expected, since each edge contributes to the diffraction. There is also colour banding which is tighter (smaller structures) for thick vanes. The double vanes show a combination of colour banding for thin and thick vanes. The banding is probably related to the distance of the edges that create the diffraction. I used a double vane spacing equal to the thickness of the thick vanes.

So there is such a thing as a free lunch? 😋

It’s not just one aspect of processing. Process steps influence each other, but usually deconvolution and star control during post processing among others are easier with moderate oversampling. It’s also easier to get decent star masks in PI. For some reason the star mask tool in PI is very sensitive to star shapes.

@Chefgage: don’t worry too much about sampling. My pixelscale is about half yours, at 0.95”/pixel, and I get good enough images with usually 0.6-0.8” guiding rms. In PixInsight I use the subframe selector script to put a weight on my images, with higher weight for lower fwhm. (I haven’t upgraded PI to the newest version yet.) Moderately oversampled images are easier to process, imo. There is a slight loss in signal to noise ratio for smaller pixels, but you compensate for that by increasing the integration time. What I did see in your image is slightly elongated stars. If your images still have that, you might have a look at optimizing your guiding.

When I taught astronomy to my 9th grade students this spring, they wanted the course to answer questions like, where does everything come from; how do stars evolve; what is the big bang; what is dark matter; how large is the universe; is there life in the universe besides us? For me, and for them, astronomy is the science that tries to figure out the really big questions: where do we come from; what is our place in the universe; what will the future bring? If we only pursue activities that have practical use, we might still be cave dwellers. Scientists don't study nature (in its broadest sense) in order to develop new technology. They do science to satisfy their curiosity, to find out things that no one else knows. Technology is just a nice byproduct. When I was a researcher, I spent four years figuring out how certain materials change when you shoot ions at them, and how you can repair them afterwards. The conclusion after those four years was, try to avoid shooting ions at these materials, because you'll mess them up for good. But, boy, did I have fun while doing what I did. And I did have several moments of sheer bliss, when I had discovered something that no one else knew. Addendum: The practical use of my research could be titled: "How NOT to make high speed lasers for fibreoptic communication"

@Robert72: Did a little more googling on double spider vanes and came across this link https://en.rbfocus.net/product-page/rb-carbon-fiber-double-spider

Do you have a sketch of this arrangement? That would make it easier to visualise. In the common 3+1 screw configuration, two of the three screws are used for rotation/tilt adjustment. The third screw is for moving the mirror up or down (together with the central screw which holds the mirror in place). Together, the 3+1 configuration creates a push pull system, with the 3 outer screws pushing, and the central screw pulling. (But I reckon you already knew this.)

Pixinsight made you stretch the data much harder, introducing noise. If you were to stretch the same in GIMP, you would also see more noise and artefacts. If I were you, I would start by restacking in PI, using cosmetic correction to remove the hot pixels, and the satellite trail. Then when stretching the image, don't apply the stf as a permanent stretch. If you want to use histogram transformation (levels in GIMP), set the midpoint slider to 0.25, leave the black point and white point at 0 and 1, and apply this several times. Bring the blackpoint in just below clipping, when you have the histogram peak well clear of the left side. This method will give you much better control over stars and background. If you want to push colour and keep detail, create a synthetic Luminance image by extreacting L from your (linear)colour image. Use arcsinh stretch on the colour image, and the above method on the L. Then combine L with colour in Lab mode, channel combination. If you still need to, apply noise reduction (not obliteration) at the end.

The common 3 screw construction allows adjustment of tilt and rotation. I would think that this method gives finer rotation control than rotating the mirror by hand. If the one screw isn't perfectly aligned with the plane of incidence and reflection, then adjusting the tilt will throw the rotation off. You will need to alternate rotation and tilt adjustment.

@Robert72: have a look here re double vanes http://geoastro.co.uk/zambuto2.htm

@old_eyes: I assume you have seen this?

If you set the camera to continuous streaming, and slowly change the focus, you can see what is happening.

I'm not entirely sure about the differences between the asi120 cameras, other than size and speed (the 120MM-S is usb3 compatible). If you want to go down the oag route, I 'd say that the asi290 is better. The asi120S has too large a body to comfortably fit on an oag. At least that is what I found with my Newtonian and a filter wheel. The 290 has a larger sensor and is more sensitive then either of the asi120 models. You will find it much easier to get stars in the fov to guide on. Usually I can use multistar guiding with my zwo oag/asi290. Only on a few occasions did Ekos have problems finding multiple guide stars. I have so far never needed to move the scope due to lack of guide stars. With the asi120S, I binned 2x2 to get better guiding. The ASI174 mini has a larger sensor, but I wonder wether the pick up prism of most oag adapters can cover the sensor. If not, then having a large sensor is a waste. If you invest in an oag, then also get a helical focuser for the guide camera. It will make focusing a lot easier. https://astronomy-imaging-camera.com/product/zwo-1-25″-helical-focuser

Sorry, no more ideas. If it isn’t stable, don’t waste any more time on it. Life is too short, and clear nights too rare. My solution was to get an ASI120MM-S, and finally an ASI290, which both just work. Your camera may work just fine under Windows, so you can probably sell it on with good conscious.

Stars will become fuzzier when out of focus. For a reflector they will become donuts, which autofocus routines generally have difficulties with. Depending on the speed of the scope, the V curve will be more or less steep. I would think that any autofocus routine has ways to adjust the focus range, because there is such a wide variety of focusers, focus motors and scopes.

That actually looks very much like the asi120 problem, where usb packet size didn’t comply with usb standards. zwo solved it by releasing the ASI120MM-S. You can try with the camera in 8 bit mode. It’s under the control tab in the indi configuration panel. 8 bit mode halves the data traffic while keeping full field of view.

The issues with the guidecam can also be driver related. The first generation asi120mm had similar problems. I got it to work by setting bit depth to 8 bits, avoiding 16 bits. No hub needed. Otoh, with my main imaging camera, the ASI174MM, I needed a powered usb3 hub. Even with 12v connector plugged in for cooling. I use a Rock64, and not a Raspberry Pi.

I tried a while back (from mag 20.5 skies), and didn't get very far with 10 hours of data: