Optimising offset for the ASI 174MM-Cool

Used last night's cloud cover to do some testing with my cooled CMOS, the ZWO ASI 174MM-Cool.
The gain of CMOS cameras is variable, and to avoid clipping dark pixels, you have to add an offset or pedestal. Basically this means that each pixel value that is read is transformed by an amplifier and analog - digital converter (ADC) according to the formula

ADU = (pv + Offset)/Gain

The odd use of dividing by gain in stead of multiplying is because gain is defined as e/ADU. One would also expect the offset to be in ADU, giving the formula

ADU = pv/Gain + Offset

But I found that at high gain setting, any change in offset is much more critical than at low gain, so I think the proper formula is the first one.

First off, you have to distinguish between gain setting ( for the ASI 174, the gain setting can be varied from 0 to 400) and real gain (about 8 e/ADU at setting 0, 1 e/ADU at setting 189, and decreasing e/ADU the higher the setting goes).

I used this simple method to determine the best offset for various gain settings.

I took one bias frame at the shortest possible exposure time (32 microseconds) for each gain/offset combination. I varied the gain setting from 0 to 400 in 100 unit steps, plus unity gain (gain setting 189). I then varied the offset and used PixInsight image statistics to determine when the lowest pixel value (in ADU) started to increase. For some reason the lowest pixel value was at least 1, so I increased offset until I got >2 - 3 ADU as a minimum pixel value.

I did the tests at -15 degrees Centigrade, because that is the temperature I use for imaging at the moment. Offsets shouldn't be that temperature dependent any way.

The highest offset that my driver (INDI) allows is 240, which wasn't high enough for a gain setting of 400. The highest gain setting that can be used with the offset at 240, is about 365.

This exercise shows that in order to achieve the highest dynamic range in the ASI 174MM, you can optimise the offset for each gain setting to avoid pixel clipping. Using a higher offset than needed to avoid clipping will decrease the dynamic range of the camera.

First steps in guiding

Finally I have taken the plunge and invested in a guiding setup. I decided for the SkyWatcher ST80 scope with ZWO ASI120MM camera. The camera is the older USB2 version.
As I don't want to take my laptop out in the field, I intend to use a RaspberryPi as a guiding computer.
The last couple of days and nights, I have been trying to get this to work. My configuration at the moment is this:
ASI120MM connected to RaspberryPi, running Ubuntu Mate as an operating system.
The Pi also holds an INDI server and the lin_guider software. The camera connects to the Pi and receives guiding pulses which it sends on to the mount (SW AZ-EQ6 GT) via the ST4 port.
Installation was quite straightforward, despite warnings that the camera driver may not be stable. Setting the exposure time to 1 sec in Lin_guider seems to work fine though.
Last night, despite partial cloud cover, I was able to test the guiding, and it worked fine.
Lin_guider connected to the camera, and frames started to flow in. Focussing was a bit of a hassle. I had to take my laptop out (despite the dew), and because there is no live view, it took a while to get focus right. In the end I had my setup guiding on Vega (which was grossly overexposed at any gain setting), and later on a nearby much fainter star. This worked fine until the stars disappeared behind my neighbour's trees and clouds rolled in.
I haven't tried imaging yet, and I still have to figure out the best settings for PID gain, but so far so good.

First experience with INDI on Raspberry Pi - part 2

Last week , when I tried to control my mount through indi on a Raspberry Pi, I managed to install the server and connect from my laptop to the indi server on the RPi. However, the mount didn't respond. It turned out that the USB serial cable didn't work anymore.
Yesterday I received an EQDIR cable from FLO, and connected it to the mount. After some adjustment of the parameters in linux and the Indi client, it all worked perfectly.
Now I can control my mount from PixInsight or any client that can run the indi protocol.
The next step will be to install and test servers.
Short recap of the installation so far.

1. Install an Ubuntu Mate image on a SD card for the RPi
2. Connect the RPi to the home Wifi network and set parameters to connect to PuTTY
3. Connect to the indi repository, download and install the indi server
4. Set $USER for dialout permission
5. Create a permanent USB entry for the connector
6. Start the server
7. Start the client and connect to the server
8. Configure the site and the mount in the client

So far PixInsight can connect to the mount and send goto commands. With the search capability, I can just search for say, M27 and the mount will slew to it.
Of course, this assumes that the mount is aligned, and so far PixInsight can't do a 2-star alignment.
I just hope that this will be implemented soon.
For the time being, my intended workflow is as follows.

1. Haul out the mount and set up
2. Level mount
3. Start mount with SynScan
4. Do a polar and a 3-star alignment
5. Park the mount and power off
6. Disconnect the SynScan
7. Connect the RPi and boot
8. Connect the client

Further testing is delayed by clouds :-(

first experiences with INDI on Raspberry Pi

Now that I have invested in a proper mount, I'm also looking into remote (15 meters) operation of it.
I don't want to drag my laptop out into the garden just to have it covered with dew, and I like the size of Raspberry Pi. This, and the fact that PixInsight is moving into the direction of hardware control through the INDI protocol, made me decide to look into the INDI solution, rather than EQMOD.
So, last weekend I erased my Pi memory card and installed Ubuntu Mate. This OS was recommended on the INDI website (indilib.org ).
Now, I have very little experience with linux, and for most of the things I do, I need to follow a tutorial or google my way around. The following is probably not the best way to do it, but these are my experiences.

Installing the OS wasn't much of a problem; download and extract the image. Then use Win32DiskImager to write the OS image onto the memory card.
Started the OS, and managed to connect it to PuTTY, but in the beginning I mainly used the desktop and a terminal window in the desktop.
Installing the INDI library took some time. For some reason I couldn't register or connect to the INDI repository (mutlaqja ppa), and the desktop on several occasions reported an internal error. Finally (don't aks me how) I managed to connect to the repository and install INDI. To get this far took quite a while so I read the OS image back to windows. I figured that if I ever need to go back and reinstall the OS, at least I won't need to do it from scratch.
I managed to get INDI server up and running, and decided to rename the USB port for permanent reference. Some googling gave the answer, and some more tapping away on my keyboard (now I don't use Mate anymore, but am connected through PuTTY and WiFi).
I then connected the mount through Synscan's serial cable and a serial/usb interface.
I managed to connect from PixInsights INDI client, but the program crashed a few times. Again, don't ask me why. I have never been able to crash PixInsight, but during the past few days I managed it twice. (Mind you, I have managed to bring it to it's knees by integrating some 200+ 14 Mpixels drizzled images. But that's a different story.)
It seems that there isn't a "hello world" application that lets you test a partial setup. There isn't even a proper tutorial that covers a complete setup. It takes some googling and looking around the INDI website to get ideas and suggestions for solutions.
Anyway, I also tried connecting through Stellarium, which didn't protest and connected to the server.
Both the PI and Stellarium connections worked fine, as the server kept responding to slew requests. However, the mount didn't budge an arcsecond.
After a long time installing, uninstalling and reinstalling various things and starting and stopping the server, rebooting the RPi, etc, etc, I finally called it a night, not having moved the mount remotely at all.
I dismantled the RPi, cables, and the mount (I'm doing this more or less in the family living room), and just as I was about to disconnect the serial cable, I noticed that neither of the LEDs was lighting or blinking.
It appears that my serial/USB connecter isn't working anymore. So now I'm waiting for the HITECH EQDIR Synscan/USB interface to arrive from Firstlightoptics.
Since everything else worked fine, just plugging in the connector should make the remote setup work. Something tells me though, that it will not work from the start, even with a new cable.

The setup sofar:
RPi 2 with Ubuntu Mate, connected to PuTTY on Windows.
sudo apt-add-repository ppa:mutlaqja/ppa (works after a few tries and reboots)
sudo apt-get install indi-full
sudo adduser $USER dialout (so I don't have to be root user to use indi)
create a rules file to rename the mounts usb port, using udevadm
indiserver -m 100 -v indi_eqmod_telescope
several reboots along the way.

To do next:
Make sure that the new connector works (without the Synscan)
Make sure that the setup works (mount connected to RPi without the Synscan inbetween; indisverver controlled by Stellarium on Windows machine)
Make sure that indiserver starts up automatically after booting the RPi.
Find and install a client that lets me control the mount and will replace the Synscan.

To be continued, I guess.