Adjusting the azimuth clutch on a Skywatcher Star Discovery mount.

Unlike the Synscan AZ, GOTO mounts, the Star Discovery Mount has FreedomFind™ dual encoder technology. This allows the mount to be pushed manually in either axis during use, and the controller keeps track of where the mount is pointing. The altitude axis has a sturdy clutch release and adjuster. However, the azimuth axis does not. With use, it is commonly found that the azimuth clutch becomes slack and the mount can be turned manually too easily. Even a gust of wind might be able to turn the scope on the azimuth axis.

Four screws hold the plastic top on the mount. When this is removed the double clutch assembly is exposed. The bottom clutch controls how difficult it is to manually turn the azimuth axis.

A spanner was made by hammering and filing a tool that came with a self assembly item, until it was wide enough to slide onto the flats on the bottom clutch. There are two Allen-key grub-screws between the flats opposite each other and these are slackened off with an Allen key. The clutch is then turned a very tiny amount clockwise and the grub screws tightened.
It is clearly a matter of trial and error to get the adjustment right, but this procedure works. It is best to turn the clutch by an almost imperceptible amount at one go. If it is overtightened, then the mount will stall while slewing in certain directions due to some asymmetry within the system.

Manufactured spanner and Allen-Key

The spanner engaging the flats

One of the retaining grub-screws is visible
I don’t know whether this procedure will invalidate the warranty, but I found that without doing it, the mount was virtually unusable. Nowhere in the manual is it explained how to correct this problem.

I use this mount as a substantial, quick setup, AZ GOTO mount for Solar system and deep sky observing and imaging. Previous postings on this blog show the mount in action. Of course there is image rotation, but as long as there is no perceptible rotation within images, then Deep Sky Stacker and lxnstack for example, are able to de-rotate the images during stacking. Keeping the azimuth clutch adjusted correctly is going to be critical for the continued use of this mount.

M17 with AstroDMx Capture for Linux and a QHY 5L-II-M

An f/5, Skywatcher Explorer 130 P-DS Newtonian Was mounted on a Celestron AVX, EQ, GOTO mount. A QHY 5L-II-M camera was placed at the Newtonian focus and AstroDMx Capture for Linux was used to capture 40 x 25s exposures of M17, the Omega or Swan Nebula as Tiff files. Matching dark-frames were captured. The frames were stacked in Deep Sky Stacker running in wine and the resulting Fits file was processed in the ESO, ESA, NASA FITS Liberator 3 software running in Wine. The resulting Tiff file was processed in Neat Image V8 and RawTherapee.

FITS Liberator

FITS Liberator is a very good program for non-linear stretching of Fits Images

M17

Full Size

Nature study with AstroDMx Capture for Linux

A Zoom TV lens was fitted to a DFK mounted on a small tripod and the camera was aimed at an active bird nesting box.

DFK with a zoom TV lens

AstroDMx Capture was used to capture a SER file of the nesting box.

Te Debian laptop capturing data

Screenshot of AstroDMx Capture for Linux capturing data

SER player was used to cut out the frames containing action. A SER file and AVI were made as high quality recordings and an animated GIF was made to show the results here on the blog.

Animated GIF

Full size

The software has the capacity for time-lapse imaging down to 0.1s intervals, but for the fast flight of the blue-tits, a 30fps SER file was the best way to capture the data

ChromeOS, Android and the SVBONY SV105 camera

There are two operating systems based on the Linux kernel that are not usually thought of as Linux. This is because, whilst they are both based on the Linux kernel, they are both, by design, unable to run Linux desktop applications. With ChromeOS, most of the applications run in the Chrome browser environment. In Android, a whole ecosystem of applications run in the Android environment, and cannot be run on a normal Linux desktop.

ChromeOS

The low cost SVBONY SV105 camera and a Chromebook.

There is no good imaging software for ChromeOS, however, there is a simple camera application that can be used in camera auto mode, and is suitable for outreach. It is even possible to grab images. Here is the setup with a Samsung Chromebook and SVBONY SV105 with a Skymax 127 on an iOptron AZ, GOTO mount, along with an image grabbed by the camera application.
Click on an image to get a closer view.

The Setup with scope, camera and Chromebook

An image captured by the camera software

Android

The SVBONY SV105 camera and Android:

The SV105 comes with a 1.8m USB cable which has a short fly-out USB lead to provide extra power to the device which has a power consumption of 150mA at 5volts. This was essential for using the camera with a Samsung 10.1 inch Galaxy Note tablet. The tablet was not able to supply sufficient power to operate the camera. A 5v 2.1A mobile phone portable charging device was used as an auxiliary power supply, connected via the fly-out lead. A powered USB hub could be used alternatively to provide extra power. My Samsung tablet was temperamental so far as detecting the camera, possibly because it is quite an old device. It helped to have the device fully charged.

Auxiliary power supply

The SV105 camera was placed at the Cassegrain focus of a Skymax 127 Maksutov and was connected to the Android tablet computer.
There is, available in the Google Play store, a USB camera capture application called USB Camera. This is a particularly good application because it presents the main controls of the camera, enabling the correct exposure etc. to be set. It works with UVC cameras.

Photograph of Android tablet streaming images from the SVBONY SV105 camera

Screenshot of USB Camera streaming video

USB Camera can capture mp4 Movies or still images.

Controls for Video formats

A drop-down menu allows the selection of the camera controls which can be hidden.

Drop down menu for camera controls

Single captured image

The combination of the SV105, Android and USB Capture provides a very credible observing, eyepiece sharing and even imaging platform.

At the moment, Android seems to be the superior of the two platforms for astronomical viewing and imaging, with one caveat; that the aging tablet used for these experiments was temperamental, even with an auxiliary power supply, with respect to detecting the camera (any camera). However, once detected, everything worked fine.
There are available Android notebooks, and depending on the version of Android they are running, they could be more suitable devices than a tablet (or phone), if they can run the capture software.
The weakness of ChromeOS is the lack of suitable capture applications.
Both platforms would benefit from the development of applications that are capable of capturing movies in the SER format, a superior format for astronomical imaging. This would produce data that could be transferred to another computer for processing.

High Definition Lunar image with SVBONY T7 W2568A camera and AstroDMx Capture for Linux

A low-cost SVBONY T7 W2568 high speed camera was placed at the Cassegrain focus of a Skymax 127 Maksutov mounted on a Celestron AVX, EQ GOTO mount. 3000 frame 8 bit SER files were captured of 4 largely overlapping regions on the terminator in the Clavius Tycho region using AstroDMx Capture for Linux. The best 50% of the frames in each of the SER files were stacked in Autostakkert!3 running in Wine and the 4 panes were stitched into a mosaic using Microsoft ICE also running in Wine. The mosaic image was wavelet processed in Registax 5.1 running in Wine. The final image was post processed in the Gimp 2.10 and RawTherapee.

Full Size

This low cost camera is definitely worth having for this kind on high definition work.

Deep Sky with the SVBONY T7 W2568A camera, AstroDMx Capture for Linux and a 10 inch, f/4.8 Newtonian

An SVBONY T7 W2568A camera was placed at the Newtonian focus of an Orion Europa, 10 inch, f/4.8 Newtonian. Exposures were captured in RAW 8, with real-time dark-frame and flat-field correction using AstroDMx Capture for Linux on a Debian laptop. The exposures were saved as Tiff files. M13 (50 x 15s exposures), M57 (30 x 45s exposures) and M82 (30 x 60s exposures). The exposures were stacked in Deep Sky Stacker running in Wine and Post processed in the Gimp 2.9 and Neat Image.

M82

Screenshot of AstroDMx Capture for Linux capturing M82 data with real-time dark-frame and flat-field correction

M57

M13

Quite acceptable deep-sky images from this low cost SVBONY W2568A high-speed camera. An ideal starter camera.

High resolution Lunar imaging with an SVBONY T7 W2568A high speed camera, a 10" Newtonian and AstroDMx Capture for Linux

An SVBONY T7 W2568A high speed camera was placed at the Newtonian Focus of an Orion, 10 inch, f/4.8 Newtonian. AstroDMx Capture for Linux running on a Debian Linux laptop, was used to capture 6 overlapping, 1500 frame SER files of the 24.8% waxing, crescent Moon. The best 50% of the frames in each SER file were stacked in Autostakkert! 3 and stitched together into a single image with Microsoft ICE both running in Wine. The resulting image was wavelet processed in Registax 5.1. also running in Wine. The final image was post processed in the Gimp 2.9.

24.8% waxing, crescent Moon

The SVBONY T7 high speed camera can produce High resolution images worthy of more expensive devices.

ZWO Gamma Gone! but not quite!

Gamma has been removed from the ZWO SDK!

This means that ZWO cameras will no longer provide a control for gamma.
At first sight this might seem like a strange thing to do, but in reality, it is not.
There is a powerful argument that image processing should be done after the data have been captured.

In general, image processing involves the selective discarding of information in the image data in the effort to recover as much information about the underlying structure of the image, such as the bands on Jupiter, or the arms of a spiral galaxy. If any of the information is discarded at capture time, it is lost forever, whilst if it is discarded post capture, it is still available in the original image data.

Gamma is such a function that involves the selective changing of the mid-range values of the brightness of an image, whilst leaving the darkest and the lightest values untouched. Many cameras allow the control of gamma at capture time, as it can produce a more pleasing view of the subject being captured. However, it must never be forgotten that the brightness values that are changed (and thus lost) will not be available in the captured data.

Experienced planetary imagers such as Christopher Go, eschew the control of gamma at capture time. What is important is to get the exposure, including gain, right at capture time. Some advanced imaging cameras only allow the control of exposure and these are often true 16 bit devices.

In order to mitigate this loss of control over gamma, Nicola has incorporated gamma control in software, in AstroDMx Capture for Linux. In addition to gamma, she has also implemented contrast and brightness in software. This allows the user to control and see a pleasing view of the subject being imaged as usual. However, the changes are not propagated through to the saved image. This means that no information is discarded at capture time and is therefore available for extraction during post processing in software such as the Gimp 2.10.

For many users, this is a paradigm shift that will require a little getting used to. However, it is likely to lead to better results in the long run.

These changes are implemented in the next release of AstroDMx Capture and have been responsible for the slight delay in release. However, the gamma camera control will be retained in addition to the implementation of the software, non destructive controls.

First Light testing of the SVBONY version of the T7 W2568A high speed astrocamera as a Linux astro-imager with AstroDMx Capture for Linux

This is a low priced astronomy camera that is a suitable introduction to astronomical imaging; not only of the Solar system but also some of the deep sky objects.
The camera is marketed as a high-speed camera and, by implication, a planetary camera.
It can be obtained from the SVBONY official AliExpress store.
I have tested the camera specifically as a Linux astronomical camera using AstroDMx Capture for Linux. The camera supplied by SVBONY was packaged well and includes a number of items.

The box contains
    • The T7 W2568A astrocamera
    • A wide angle lens
    • An auto-guiding cable
    • A USB 2.0 cable
    • An IR/UV cut filter assembly
    • An extension nose-piece
    • Two dust caps
    • A par-focal ring with three thumbscrews. place

The camera with the par-focal ring in place

The par-focal ring is of a superior design with the three thumb screws engaging on an internal O-ring so the screws don’t actually make contact with the camera (or eyepiece) body.

One of the first things to do with a camera of this design is to place a patch of insulating tape over the auto-guiding port. This will ensure that the camera USB cable is not accidentally plugged into the guiding port in the dark. Some manufacturers provide a blanking plug for this purpose but many do not.

The auto-guiding port protected by insulating tape

The substantial par-focal ring can be seen clearly with its three retaining screws.

There are very handy calibration marks on the side of the camera body, making re-positioning much easier.

Calibration marks on the camera body

The camera reports itself as a ZWOASI120MC although it contains a MT9M034 sensor rather than the AR0130CS of the ZWO. The camera will stream 8 bit images and it will stream 16 bit (12 bit in a 16 bit container) images for short exposures. The camera will not reliably deliver 16 bit long exposures. This is not a serious limitation for a camera of low cost. (Moreover, a similar issue is evident in the USB 2.0 ZWO with 16 bit long exposures if the compatibility firmware is used.) In this experiment, the standard camera firmware was used, and a Linux machine with the kernel patched to eliminate the maxpacket limitation in the USB data stream was employed. Note! with the Linux Kernel 4.16.8-300.fc28.x86_64 released by a Fedora 28 update on May 15, 2018, no kernel patch is needed. 16 bit short exposures could be advantageous with solar imaging where the capture of subtly different levels of brightness is important. With 8 bit images, 256 distinct levels of brightness can be recorded, whereas, with 12 bit output (into a 16 bit container) 4096 distinct levels of brightness can be recorded.

Deep Sky imaging

The SVBONY T7 astrocamera was placed at the Newtonian focus of an f/5, Skywatcher Explorer 130 P-DS Newtonian mounted on a Celestron AVX, EQ, GOTO mount. 30 x 20s exposures of M3 were made with real-time dark-frame correction, saving the images as TIFF files using RAW 8 capture with high quality de-bayering on the fly.

Screenshot of AstroDMx Capture for Linux streaming images of M3 without real-time dark-frame correction

Note the background noise in the displayed image.

Screenshot of AstroDMx Capture for Linux streaming images of M3 with real-time dark-frame correction

Note the removal of the background noise by the real-time dark-frame correction.

Animation alternating between the real-time dark-frame corrected and uncorrected views

The real-time dark-frame correction is ideal for outreach and ‘eyepiece sharing’ observing and imaging.
The images were stacked in Deep Sky Stacker running in Wine and post processed in The Gimp 2.10

M3

40 x 35s exposures of M104 were made with real-time dark-frame correction using AstroDMx Capture for Linux, saving the images as TIFF files using RAW 8 capture with high quality de-bayering on the fly.
The images were stacked in Deep Sky Stacker running in Wine and post processed in The Gimp 2.10 and Neat Image.

M104

Planetary imaging

The camera was then tested in its high speed planetary camera mode. The lens from a x2 Barlow was screwed onto the nose-piece of the camera which was then placed at the Cassegrain focus of a Skymax 127 Maksutov. A region of interest of 320 x 240 was selected and a 2min SER file of Jupiter was collected (under poor seeing conditions) using RAW 8 capture with high quality de-bayering on the fly. 10,000 frames were captured. The best 40% of frames were stacked in Autostakkert! 3 and wavelet processed in Registax 5.1 both running in Wine. The final image was post processed in the Gimp 2.10

Jupiter with the GRS

First impressions of the SVBONY T7 camera are that is is a very good value device, ideal  as an introductory camera for Solar System and brighter deep sky object astrophotography. It is an impressive device and has capabilities that will produce pleasing results. Depending on the exposure, with a region of interest of 230 x 240, a frame rate of up to 250fps can be achieved. It should also be noticed that relatively small aperture telescopes have been used for the current tests. Later testing will involve the use of much larger aperture telescopes.

Deep sky with a QHY 5L-ll-M and AstroDMx Capture for Linux

A Bresser Messier-AR-102-AS ED refractor was mounted on a Celestron AVX, EQ, GOTO mount. A QHY 5L-ll-M camera was placed at the prime focus. AstroDMx Capture for Linux was used to capture 16 bit FITs files with matching dark frames.
M104 ans M64 were captured with 20 x 50s exposures M3 was captured with 40 x 16s exposures.
The Fits files were stacked with dark-frame correction in Deep Sky Stacker, running in Wine. The resulting images were processed in FITs Liberator and post processed in The Gimp 2.9.
With M3, the stacked image was processed by four transformations in FITs Liberator (arcsin, root, log(root) and log(log)). The images were converted to BMPs and combined with weighting in Andrew Sprott's Flexible Image Combine (FIC).

M3

M64

M104

FULL SIZE
M3

M64

M104

Jupiter with an SVBONY SV105 camera, a Skymax 127 and AstroDMx Capture for Linux

An SVBONY SV105 camera was placed at the Cassegrain focus of a Skymax 127 Maksutov. AstroDMx Capture for Linux was used to capture a 3 min SER file of Jupiter. The best 25% of the 2292 frames captured were stacked in Autostakkert!3 and wavelet processed in Registax 5.1, both running in Wine. The final image was post processed in The Gimp 2.10. Ganymede and the Great Red Spot are both visible.

Considering the fact that the seeing was poor and the telescope only has a 5" aperture, the detail in the image is acceptable from this low cost camera.

Bug in the recent Linux kernels affecting Video 4 Linux

There is a bug that has been introduced into the Linux kernel since April 12, 2018.
The bug manifests itself as each V4L camera on the USB bus being presented twice. This is the information I have at the moments on the versions involved:
This problem has been found on Fedora kernels but may be present in other kernels.

Fedora Linux kernel version

4.15.17    Apl 12    works correctly
4.16.4      Apr 24    kernel bug displaying 2 devices
4.16.5      Apr 27    kernel bug displaying 2 devices

In AstroDMx Capture for Linux, the bug shows itself at connect time:

Screenshot of the camera connect dialogue showing the cameras presenting twice

Everything will work fine if the first instance of the device is chosen.
It should be noted that this is a bug in the Linux kernel, not in AstroDMx Capture for Linux.
The bug has been reported to the kernel developers and we shall have to see how long they take to fix it. At the moment one can solve the problem by booting into an earlier version of the kernel, or by simply choosing the first device when two are presented. Cameras that are not V4L cameras are not affected.
Nicola has implemented a workaround to eliminate this problem. It will be present in the next release of AstroDMx Capture for Linux.

The terminator of the 98.5% waxing, gibbous Moon with AstroDMx Capture, a SVBONY SV105 camera and a Bresser Messier-AR-102XS ED refractor

An SVBONY SV105 camera was fitted with a Baader green continuum filter and a x2 Barlow using the refractor at f/9. AstroDMx Capture for Linux was used to capture 4 overlapping, unsaturated, 1500 frame SER files with real-time flat-field correction of the terminator of the 98.5% waxing Moon. The best 75% of the frames in each of the SER files were stacked in Autostakkert! 3, wavelet processed in Registax 5.1 and stitched into a mosaic by Microsoft ICE, all running in Wine. The final image was post processed in the Gimp 2.9.

Using the Barlow still allowed significant oversampling with the 3 micron pixels of the SV105. The 10nm bandpass continuum filter in the middle of the visible, provided light reduction for the very sensitive camera, and eliminates any possible dispersion, notwithstanding the ED objective of the telescope

Modifying a Celestron Omni XLT 150 Newtonian for using a light pollution (or other) filter when a DSLR is directly connected to the telescope.

The Omni XLT 150 f/5 Newtonian, shares a problem with a number of other Newtonians in that when a DSLR camera is connected to the focuser via a 1.25" adapter, the scope does not have enough back focus to allow the image to be brought to focus.
The solutions to this problem have been:

• Use a Barlow lens to increase the focal length of the system. This allows focus to be achieved, but at the expense of brightness of the image and field of view.
• Move the position of the mirror further up the tube. This is a drastic solution, and is particularly difficult with the Omni XLT 150.
• To use the direct camera connect threads on the focuser that allow a camera T-ring to be screwed to the end of the focuser tube. This has the advantage of allowing the camera to be brought to focus. Another, important consequence of using the direct connection method is that the camera cannot fall out of the focuser as could happen with a 1.25" adapter, if the tightening screws have become loose. Moreover, with direct attachment, there is less potential for vignetting. However, there is a huge disadvantage to the direct attachment method: it is not possible to use a light pollution filter, which makes a critical difference if the sky suffers from even slight light pollution. Moreover, if the user wishes to use any other filter, the same problem arises.
• There are also, some astronomy cameras that do not have a filter-threaded nose piece. With some scopes this is not a problem because a threaded extender tube can be used. However, with many Newtonians this is not possible because the camera is now held too far out to achieve focus.

We show here, an experimental method of allowing a 1.25" light pollution filter to be used with direct camera connection. This is a solution that could be adopted by Celestron (or any other manufacturer) at very little cost, as a standard component of the focuser.

First, a Barlow lens was disassembled so that the middle tube, which is filter threaded, could be removed and used as an internal filter holder in the focuser tube.

A thin shim of plastic tape was placed around the middle tube and it was inserted tightly into the focuser tube and fixed in place with superglue.

The filter threaded Barlow tube was pushed far enough into the tube to allow the 1.25" adapter to be screwed back into place for normal eyepiece work. This adapter has to be removed for filter insertion and direct camera attachment.

After removal of the 1.25" adapter, the Light Pollution filter can be screwed into the Barlow tube threads.

The T-ring can then be attached as usual, ready for direct camera attachment.

Or the 1.25" adapter can be replaced, with the filter in place, for use with a camera that does not have a filter thread as in a camera tested recently.

It is unlikely that this procedure will introduce any more vignetting into the image than would have been produced if the scope had enough back focus to allow a 1.25" adapter to have been used.

In my view, any scope with the facility to attach a DSLR directly to the focuser, should have a filter threaded section inside the focuser to allow the use of filters, in particular, light pollution filters.