Bob had noticed a lot of dirt on or near the sensor on the QHY168C camera that forms part of the imaging train on the Tak FS102. Today I took the camera off for a little spring clean.
The first thing was to mark the rotation angle of the camera so that it goes back on exactly. 21 degrees is the rotation angle as measured through an actual image.
Taping up position angle on QHY camera
Next I took the camera off loosing the 3 screws holding it in position and then took a look at the CMOS chop glass cover for dirt.
Inspecting QHY168C for dirt on glass cover
There was really only a couple of pieces of dirt on the cover so I removed them with the blower.
Rocket blower
Next I took off the extension tube with which has the glass UV lens inside. At this point I forgot to mark up the position angle when I took the extension tube off. So when I reattached I look at the image train photo to adjust. Hopefully it will be very close and will only require minor adjustment.
Tak FS102 QHY168C imaging train
Looking at the UV filter it was instantly visible that there was plenty of dirt and dirt on the glass lens, however it transpired to be on the inside of the lens toward the OTA. O removed the filter to clean with the rocket blower.
UV glass filter dirt and dust
I then reattached the filter, the camera and reset the angle. I followed up by feeling for any play in the Tak OTA bracket that piggy backs it on the OS12″ OTA. I could not feel any. I was checking due to a shift on the FoV when Bob was recently imaging. Again the next time out we will need to readjust.
Back out again tonight for a short period to look at guiding again. So with everything setup and a longer USB 2 cable in use I am now sitting in the warm Orangery. I will try again with the PHD2 software to guide and EzCap to acquire images from the QHY168C. I have set the Gain to 7 and Offset to 30 as previously used on my other QHY168C when used in Tenerife.
I polar aligned using PoleMaster. Then set about syncing the scope with Betelgeuse. It was only off slightly. The sync worked fine tonight. I then slewed to M35 and started the PHD2 guider software, selected a guide star and calibrated the guider. This worked well first time proving my new step size of 4 using a small ms time for the pulse worked.
Then I started guiding and very quickly realised the same problem as yesterday with DEC drift upwards. No amount of fiddling with the setting such as Hysteresis or Aggressiveness changes the constant upwards drift. I then remembered that I could calibrate the settings as the other night under Guider Assistant. I ran this made the changes but still the upward drift.
I then remembered that on the Paramount MEII in the dome I had to drift align with PHD2 to get it properly polar aligned and that PoleMaster was only good enough for short exposures or rough guiding. So I set about drift aligning.
PHD2 Drift Alignment
The first thing to note is that the polar alignment was out by a fair bit to get the accuracy I require in both azimuth and altitude. I have now adjusted both and the graph seems a lot smoother.
So in all it took me around 1 hour to drift align and just as I was about to test the clouds rolled in!
Tonight I wanted to continue to try and get guiding working, I setup outside on a much calmer night, no real wind tonight. Bob once again is playing with the IMT3.
I setup in the same place on the patio and again fed the USB cable through the window. I used the Polemaster to get the mount in the right position and then slewed to Betelgeuse to see if it was in the centre and it was!
I then slewed to M35 and connected the guider with PHD2. After some back and forth I got it calibrated but it was complaining about the amount of steps being to small for calibration and the guiding was all over the place. The screen brightness was still very white. I solved this by changing the Gain for the camera.
I decided to give TheSky X a go at guiding instead of PHD2. Unfortunatly it was not much better and at one point I could see the downloaded image from the guider then suddenly it disappeared, I had changed nothing but now it was black. Nothing I could do would make it come back including disconnecting. So I went back to PHD2.
I managed to fix the issue in PHD on the amount of Steps being used to calibrate by adjusting the calibration step size down from 5333 to 1300. This increased the steps from 3 to 5. Much better and now I don’t get the error.
PHD2 good calibration
However right now I still cannot get the Dec to behave. Whilst I can take a 5 min image the Dec is wonder up from where it should be and no amount of tweaking the Aggressiveness or Hysteresis changes that.
Furthermore, I decided to take images with The Sky X over EzCap but after 4 images TSX hangs every time……. So I have now given up tonight and will come back out the next cleanser night to resolve the issues.
First time out for a very long time with the travel setup. I need to get the guiding working before the Tenerife holiday in July. I have left Bob to play with the IMT3 whilst I work through the bugs.
The challenge is at first remembering how to set everything up. I found after some effort I was actually missing a cable, it was in the black wheelie case in the garage with the laptop tent and scope daytime cover, but more about that later.
So So after finding a place on the patio where I could feed the USB cable through the Orangery window, I put the Berlebach tripod down and placed the MyT mount on top. I tightened the screws and then placed the Sky-Watcher Esprit 120 ED on top of the Versa Plate. Once in position I balanced the scope then connected the various cables, now all through the mount due to my good friend Bob making up some power connectors for me.
So I tried to guide through PHD2. There was a large wind blowing. On trying to calibrate the scope would not move. After what seemed like an hour I remembered that cable, this was again the ST4 guider cable that is needed on the Mac if you are guiding with PHD2 as there is no ASCOM. So I connected the ST4 cable and it worked.
What I could not achieve tonight was to get the guide graph behaving, it was a mess. The wind was at fault but still there were other issues, not least the slider to control the contrast of the screen was causing anything above 0.5s to become white.
Guiding a mess with PHD2
After many hours I gave up and brought the rig in. I had been using TheSkyX to slew there scope, PHD2 to guide and EzCap to connect to the QHY168C camera and take images. I will try again tomorrow night.
I managed to get only 45 minutes worth of data the other night to test if I could both acquire data and then process it. It took some time to get the downloaded HOPS software from the ExoClock mission working on my Mac, but with the help of Angelos from the project. So I opened the 46 images, I did not capture darks or flats and of course no bias due to it being a CMOS camera. I added information about the observatory and then ran the reduction and alignment code.
Completion of details and opening of 46 images
So the initial chart looked promising, I had taken the first set of frames almost on time for the transit even though you are supposed to start 1 hour before. This was because it took me so long to setup. So the data looks like it shows a decrease in brightness over the 45mins, however I have asked Angelos for his opinion and await a response.
Output from clicking Run Reduction
I then selected the target star, KELT-18 with the red circle below, along with 5 comparison stars. I may have selected stars incorrectly here as they are probably suppose to be not variable.
Alignment and comparison star window
The resulting table appeared with the size of the box for each star and its position.
Resulting target and comparison stars
I then ran the photometry code and the following chart was created which to me showed I had done something wrong given the scatter.
Graph output with actual photometric values and PSF in red
I then for fun ran the fitting code from this screen.
Information for Fitting
The fitting showed and increase in brightness which was clearly incorrect. So I have learned a few things with this, first is to read up on using the software for analysis, second is to gain more data and calibration frames.
Resulting output clearly showing problems with data
Slightly hazy right now but I have opened the dome up and turned the cooling fans on the 12″. Slewed to Atik, a mag 2.8 star in Perseus and aligned the scope.
Atik mag 2.8 star in Perseus for alignment
So the star was almost in the centre when I slewed the scope to it, a slight tweak and now synced on it centrally. The Hitec Astro weather station reports slight haze
Hitec Astro Weather Station showing haze
Gingergeek installed a new Intel Windows small form factor computer recently in replacement for the RPi so we could run the AllSkEye software and see if the loss of one of the colour channels was software or hardware. Here is tonights image, which still needs colour calibrating during the day.
As always on Christmas Day, or at least it seems so, the sky was clear for a period of time before the clouds rolled in. The day was dry and cold, sunny and bright, the first time in over a month of rain. Now was the time to take a look at a star and see if I could calibrate my setup for imaging an exoplanet transit.
All Sky Camera
I used the exoclock.space website to find objects for my location and then entered the RA and DEC into The Sky X (TSX) and slewed to it. The star and its associated planet tonight was KELT-18 and the planet KELT-18b. This was very low to the North when I slewed and I struggled doing a slew and sync with the scope in TSX due to not enough stars found.
Exoplanet Target List from Exoclock.com
So instead I placed the RA and DEC into SGPro and asked that to perform a slew and solve, which incidentally worked an absolute treat. The star was centred in the middle of the FoV and the star pattern matched that from the Exoclock website which they give you.
Kelt-18b details including interactive star map
I then setup SGPro to take as many images as I could, each being 1min long as I could not find a guide star. At 1min I did not get any trailing and I should have said, all of this through the 12″. I set the cooler to -28℃ which consumed about 26% power so nicely cold. I choose the red filter as described to lower the amount of noise in the image and allow calibration with other astronomers images.
Resulting image
I had to change the user profile to the Comet profile as I did not wan the guider trying to settle, so restarted the run and was off. I managed to go for around an hour and thus grabbed 46 images. I am not sure if I can use the HOPS software from Exoclock to plot these but will try. I did not bother with calibration frames and if needed I can grab some later.
SGPro sequence running
Either way, a good hours viewing in-between the outgoing festive cheer from one side of my family and the incoming festive cheer tomorrow from the other.
Tonight I wanted to get the PHD2 guiding working when doing a meridian flip without the need to calibrate. A month ago we still failed to get this done, however a little experimenting tonight and changing a single setting has corrected the problem. The setting was the ‘Reverse Dec Outputted After Meridian Flip’ one within the Guiding table of the Advanced Setup, for which I ticked and this fixed the issue.
Reverse DEC output after meridian flip needed ticking!
I then decided to try 2 objects either side of the meridian and that worked manually slewing to each and then guiding. What did not work was the slewing automatically to the object in terms of centring on the screen. It slewed to the star, I could see it on the screen, the first object Almach worked ok, but the second object, Deneb appeared on the screen but failed to centre with the error ‘ Failed to auto centre, aborting sequence’ followed by ‘ failed to centre on object with an error less than 50 pixels’. Plate solving works fine, well at least it comes back with success.
Error message failing to centre
So I tried different sets of co-ordinates from TSX including the Topocentric and 2000.0 sets. Neither made a difference, with 2000.0 data used I still got this set of errors which shows an error in pixels of more than 50 in DEC.
DEC Error when centring
So I decided it might be the very bright object I had picked, star in this case, that was causing the problem. So to further my experimentation this evening I choose two different and less bright objects, M36 and M39, once again on different sides of the Meridian. Success !!
60s uncalibrated guided M39 exposure
So after fixing this I am now happy to go off to bed early (9:30 work tomorrow) with a job well done.
GingerGeek and I tried to sort a few things last night, namely PHD2 guiding on both sides of the mount without any recalibration, automated meridian flip within SGPro, focusing and plate solving. After nearly 2 hours we had not fixed any of these problems. So we need further research/reading to resolve.
Instead @9pm I decided to take some more images of M76 since it was due to be fairly clear all night. What I found was this was quite simple to now setup and get working as long as I did not mind performing a manual flip at 11:30pm.
There was one other issue last night which was around the dome closing, it suddenly did this around 10pm, not sure why, I think (I now in the light of day cannot be sure) the relay went off. Looking at the Keogram and then the ASC movie for last night it does coincide with a set of cloud going over so maybe that is why it closed. It will be nice to then get it to reopen when clear, another thing to fix at some point.
So as I say, setting up for the run was straightforward and I used TSX rather than SGPro to centre and platesolve M76 as normal. I then took a sample image of 60 seconds found that the focus was more or less spot on for OIII, despite earlier challenges with focus not working and all was ready to go.
On the point of focus problems, we could not get an accurate V-Curve earlier in the evening, SGPro kept coming up with different focus points after each run and eventually we put this down to the dome and scope not having had time to cool given it only being 30 minutes or so. The outside temperature was around 3℃ whilst the inside was just shy of 9℃. Later in the evening the difference was much smaller (I should remember to record this). I can get the ambient temp for the outside the next day from the FITS header but I have no record of the inside ambient temp, something else to fix.
So I went off to bed just after the meridian flip around 11:30pm and after watching a few frames come down. This morning I took flats and darks and closed the dome which was still open with the first frost of the season having set in and frost was covering the inside of the dome.
Quick set of images this evening to take some more data of M76. I can image for 3 hours before a meridian flip. I need to get the automated flip working and thus the plate solving that seems to be having issues. For now I will open the dome and just set it running on OIII through the 12″.
After entering with TSX connected to the ASI camera I started guiding and for setup reasons I have included the guide star here.
Guide Star
@00:45 I managed to do the manual meridian flip and then headed off to be after collecting another 2 hours of OIII data. I left the scope running for the rest of the night knowing that the dome would shut if the sky clouded up.
Last image taken
So I am now up at 7am and indeed the dome closed when the clouds rolled in. I have no real notification of when that occurred so I have now set the HitecWeather station software to log on the triggering of the relay to a file so I can see the time it closed.
Alerts now setup
Logging setup for alerts
This will allow me to compare to the Keogram from the ASC and double check the dome is closing at the appropriate time.
Fortunately SGPro is connected to the weather station as a safety monitor and stops imaging if the dome closes. I can see the clouds started to roll in around 1:30am for a few minutes then just before 2pm there were more and by 2:43am after they covered the sky. The good thing is it looks like, although I cannot be sure, the dome would have closed at around 1:50am which is the time of the last image taken assuming the date stamp is the completion of the image.
Safety enabled
I have now taken flats and darks and parked the scope and it is ready for it’s next outing, I also remembered to turn the dehumidifier back on this time. Both the dehumidifier and the flat panel need connecting to an Arduino to automate turning on and off.
View from cameras when in position to flat panel on 12″
At the IMT we were experiencing stability issues with the ZWO ASI120MC USB3 camera on the MAC/NUC so we decided to move it to it’s own Raspberry Pi4 (4GB) as a cheap experiment.
The Raspberry Pi4 has the advantage of improved networking and connectivity including USB3. One of the downsides of the RPi4 is the increased heat generated by the CPU which is mitigated by housing it in a FLiRC passive case to dissipate the heat and prevent thermal throttling.
Additionally in order to prevent SD card wear and improve the I/O throughput we configured the RPi4 just to boot off the SD card but serve the rest of the file systems from a SSD connected via USB3.
AllSky Camera Software
Using the open-source AllSky Camera project for ASI camera support we gain some advantages. The main advantage is that it’s open source (served via Git), provides an admin and public web portal which is addressed locally as http://allsky.local and the software can be set to start on system startup.
Admin Web Portal
The allskycam software can restart on system reboot but it can also be stopped/restarted via the web admin portal.
The configuration is simple and the mode/behaviour of the software can be controlled via the GUI or via a settings.json file from the command line.
Admin Portal – Camera Settings
I recommend you take the time to create a dark reference image, again this is done via the GUI panel as long exposure frame will show extensive hot pixels.
RGB24 image hot pixels with no dark applied
Non Admin Web Portal
This is accessed via the address http://allsky.local/allsky-website and provides the latest captured image, a constellation overlay and the ability to view time-lapses and star trails.
Local network web site for non admin users
One of the nice features of the software is it’s ability to create a time-lapse of acquired images for the previous night. The following video shows the debayer issues as well as the dewing of the dome cover.
Time Lapse of evening showing dew issues/grayscale bayer
Bob is due to connect up the resistor ring he’s placed around the camera which hopefully should fix the dome dewing we encountered on the first night.
So it remains for us to fix and implement the following :
Resolve the lack of colour images (RGB24)
Image quality breakup
Resolve dark daytime images
Secure copy latest image/time-lapse to an external public website
Scale VirtualSky constellation overlay (180 degrees) down to 150 degrees
After nearly a month of not imaging from IMT due to a holiday in Tenerife, a week in New York with work and then Manchester and London along with a run of poor weather it was clear on a Saturday night! Another evening commissioning the observatory was needed, so tonight we will again further refine the polar alignment since the last major modification and distribution of weight where we changed the adjustment plate for Bob’s Tank FS 102 OTA. Again we plan to drift align with PHD.
First thing is to find a star near the celestial equator near the Meridian so that it would display the most movement and thus magnify the error of miss polar alignment. I should be able to find HP 95501 @8pm.
Star to drift align for Azimuth
Next I performed an autofocus using the Luminance filter. HIP 95501 is the star to choose for drift aligning the first part, a 1 second image within Frame and Focus in SGPro showed it just off centre which was fine.
Star to guide on
Next I moved the star to place in the Lodestar FoV. Now I can measure the azimuth polar error, ALWAYS ignoring the RA line. Looking at the Dec line I could see I was out by 2.43′ and 39px. I adjusted the thruster knobs on the MEII to move the star to the outset edge of the purple circle showing the error, in this case the right thrust in and left thrust out. I then drifted again and make sure the purple circle gets smaller and the DEC line a much shallower angle.
After first adjustment 0.53′ and 34px out
I adjusted again and got the azimuth error down to a respectable 0.08′ 5px error.
Azimuth error 0.08′ 5px
The graph on PHD2 should started to look fairly flat, and so I then attempted to fix the polar error for altitude. I selected a star in the West and near the celestial equator such as Rasalgethi in Hercules.
Rasalgethi used for Altitude adjustment
I watched the DEC line only and ignored the RA, the DEC line this time reflecting the error in altitude. Then I adjusted the mount using the altitude adjustment spanner moving the star again to the outside of the purple circle and then retested, finally getting the error down to a suitably small number after only 1 turn of 0.12′ 5px error.
Altitude adjusted to 0.12′ 5px error
Unfortunately at the extreme West I could only expose unguided for 1min on the 12″ at 2.5m focal length, the stars otherwise looked trailed.
Trailed stars at extreme due West
I then went to near the meridian and a 4 min exposure produced nice sound stars.
4 minute exposure near Meridian
I then went on to do an automated TPoint run, but the problem seemed to be that a large number of samples could not be solved. The resulting TPoint model of 118 samples of which only 90 were usable, was worse than the 60 point model I had before. I will therefore redo the TPoint model the next time it is clear.
TPoint model not as great at 60 points I did before
The whole 118 model took approximately 1.5 hours to complete which is so much better than a manual model.
Completed model 118 points
The good thing is the TPoint model told me the polar alignment is excellent!
Polar Alignment is excellent 🙂
It is now @23:30 so I went on to start imaging. First I needed to perform a focus run on Luminance which I did.
Good focus on luminance
I then slewed to M76 to start my image run, a 30s exposure showed stars in focus and little dumbbell prominent in OIII.
Focused stars and M76 centred
This time round I decided to set the Gain to 139 and the Offset accordingly to 21. I also decided on a 10min exposure rather than 20mins front the last set.
This evening started with the Moon high in the sky and waxing its way to half. Next to it Saturn sat, close in fact, so close I pointed the scope at it, around 22:30 and both the Moon and Saturn fit in the same field of view 🙂
So I took a few exposures, worried that either the Moon would be overexposed or Saturn underexposed. I settled on 0.001s and took a bunch of shots. Below is my setup by the light of my rather bright head torch, turned on only for this photo I might add.
Esprit 120 and MyT
Next it was back to trying to resolve the guiding issues that had troubled me the night before. The good news was Tom from the Software Bisque website (not the Tom Bisque, another Tom) had come back with a few suggestions and questions that made me think. I had a good set of guide stars to choose from.
Hw many guide stars!
The autoguide Setup window is where I would spend most of my time I was sure, changing parameters.
Guider settings
I recalibrated the mount, this time using 100arcsec as the parameter. The previous calibration run produced a rather short cross.
Poor calibration ?
This gave me a better ‘cross’ and I think should improve the guiding, although I am still skeptical about just how quick it calibrates, some 4-5 seconds.
Better calibration
Back to guiding the mount was still all over the place, I am convinced it is overcorrecting, on the basis if I don’t guide I get better stars up to 45s or so. I added in a much longer settle period and this seemed to help, but still the graph is a long way from the sort of guiding I was getting before they updated the software.
Poor guiding
The wind was a bit gusty tonight as last night and for sure this was not helping, you can tell from a few exposures it was wind related jumps and drifting
I sat back after a while of changing different settings feeling that it was not improving, so I took a whole bunch of images, only 90s of the Sharpless object Trevor had mentioned, SH2-101 which is called the Tulip nebula. Trevor had produced a lovely image from his 14″ in the UK so I thought I would have a quick go, knowing most of the frames would be lost.
Final set of guider settings
So by 00:30 I decided to start to pack up, the wind had picked up, I was cold, the guiding was still a problem, so by just gone 1am I was heading down the mountain, some 1 hour and 20min drive! The final view from the bridge as it were was this.
View from TSX
The next day I processed the data for the Sharpless object and it was ok, given the short amount of data. One for the 12″ I think.
SH2-101 Tulip Nebula
Meanwhile I processed a single image of the Moon and Saturn and was pleased with the result as seen above. Here is a version with Saturn as an insert.
So I have arrived in Tenerife and for a few nights only I am up at the MONS observatory, using the plateau (concrete platform with power) outside the dome.
It was dark when I arrived at 20:15 so I am setting up by head torch and given the tripod and mount and scope are all in bits it has taken some time to put it back together.
I setup in the corner where Bob normally sits as thee were a bunch of students using the scopes normally kept in the sheds outside. After setting up I panicked as I had forgot my UK to EU plug ! I asked the lady leading the student outreach and she let me in the MONS and I searched for a plug and found one, despite everything being emptied out due to the MONS having work done to it. However on testing the plug it did not work 🙁
A call to the operator did not produced anything. So I tore down the scope and packed in the car, very disheartened. As I was just about to head off the operator arrived with another plug ! I took my laptop and tried it, but it did not work either. It took a while to work out but of course the power had been turned off from the fuse box and flicking the RCD produced power and so reluctantly I emptied the car and went about setting back up 🙁
By this time it was approaching midnight and I had been at this for some 4 hours. I started the laptop, found I was pointing almost spot on to Polaris, so using my Polemaster it took a few minutes to adjust. I then set about slewing to a nearby object, syncing and then finding a guide star, at this point my troubles where just about to begin. It was now 1am.
So after setting the temperature of the camera to -25℃ and the gain to 7 and offset to 20 I found the scope would not guide. It was bouncing all over the place, some of it was the wind, but some of it was erratic behaviour of the mount, so it seemed like it was overcorrecting. I started to change some of the settings but t no avail. All I could do was to shortened the exposure to around 90 seconds and try and get some data, even if the stars were slightly trailed. I would try to take a longer look at the guiding tomorrow night.
Not so great guiding
So I slewed to one of the objects I was to target, a galaxy called NGC 891 in Andromeda and started collecting data. All in all I grabbed 44 images before the guider was causing so much of an issue even 90 seconds was too long (processed image below)
I then slewed to M45 in Taurus but still the guiding problems persisted. I took 4 x 90 second images and then decided to call it a night at around 3:30am.
Now for packing up the scope and the 1 hour 20 minute drive back down the mountain. How I miss observing from Hacienda on La Palma!
So the main approach here was to start testing the ZWO ASI1600mm on 5min images and decide which is the best Gain and Offset to use. As the object is a planetary nebula I have used my Astrodon 5nm OIII filter to bring out the faintest parts of the nebula. To be thorough, and this will take time, I plan on running the tests for all 7 filters I have.
I have done extensive reading on the topic of image analysis and hope to apply here what I have learnt. Given then camera is running 12 bit, I have a maximum pixel value of 4096 which represents saturation and then any further response is non-linear. Once I have completed 5min testing I will try for 10, 15 and 20 mins. I will then perform further testing by taking a sample set of 10 images to stack and see how that compares with similar total exposure times across the frames.
Amp glow is a particular problem with CMOS. Despite the ZWO site suggesting that amp glow is virtually removed in the Pro Cooled camera, it is clearly not, as can be seen in single 5 min subs. The good thing is a dark will remove it effectively. What I need to make sure is that the amount glow does not swamp the image so much that it overpowers the signal from the faint nebula.
Increasing the gain and offset value from left to right you can see a marked increase in the amp glow. The image slices below are taken from the far right of each frame.
The offset figures in relation to the gain figures have been taken from my reading of various material. The median values are that of the background and the maximum values that of the stars. You can see on this 5min exposure that by the time I reached a gain of 300 one or more of the stars are saturated. In fact the brightest star in this slice is SAO 22510 which is mag 9.53.
Another way to visualise the saturation effect is looking at the raw unstretched image, whilst a star is visible in the image using gain 139 and 200, on close inspection within PI and looking at the values of the pixels of the star they are not saturated. However gain 300 is. The purpose of this is that an unstretched image is not the defect for telling if parts of the image are saturated as some texts describe, but one can see the increased brightening of the star by gain 300 to know it is a problem.
So whilst I have seen the clipping a a few stars at the highest gain I have tested, what about the planetary nebula itself? From the below stretched image one could assume that the brightest part of the nebula was fairly bright and heading towards saturation, but don’t be fooled! Also there is a noticeable increase in the background brightness as the gain increases.
Again as for the amp glow, the aim is to balance the ability to amplify the faintest parts of the nebula without swamping them with the background brightness.
Again here are the values of the settings for gain and offset against the central section of the image.
So how bright did the background get? The graph below shows a section of the background free from stars and charts the increase of brightness from a mean figure of 9 ADU with the gain set to 0 and a mean figure of 104 with the gain set to 300. So a large increase but but at least up until gain 200 not a problem, as we will see when we look at the faintest part of the nebula later.
This graph looks at the bright star SAO 22551 (HIP 8063) which is mag 6.66 and the brightest star in the image. Again as previously seen in the right hand slice of the image the star is saturated by gain 300. All figures are the maximum pixel values.
Now let’s focus on the nebula itself and go back to using the mean ADU figures. The picture below shows the section of the nebula I will use for analysis. In particular I focused in on the brightest lobe of the central portion of the planetary nebula and the faintest portion of the left arc.
So looking at the faintest nebula within the left arc we can see that it is not very bright at all and the brightest it gets at gain 300 and offset 65 has a mean figure of 96 ADU. Each and every image at the different gain setting and offset setting is seemingly just below that of the background, which in itself is interesting as the nebula seems to be fainter than the background. So more analysis was needed.
However I then went back and looked at a selection of areas of the background across the image to find that the original background selection to the bottom left of the image was brighter than other areas. Below you can see the image of gain 200 and offset 50, this time with 5 selection boxes. Preview 6 is the nebula as recorded before is mean 56 ADU. Preview 5, so the sky right next door to it has a mean figure of 55, so just below the nebula, hence it is only barely visible. Preview 1 is 54 ADU and Preview 4 is also 54 ADU. So there is brightening on that bottom left corner of the image, so had the nebula fallen at that spot then it would be swapped by the background.
There is only 1 ADU between the nebula and the background adjacent to it at gain 200 offset 50. If we looked at the same to regions in the image of gain 300 and offset 50 then you get a 2 ADU difference. The image with gain 300 and offset 65 gives a 3 ADU difference. So the results show that both gain and offset both help increase the contrast between the background sky and the faintest part of the nebula.
Various previews can be seen to analyse the background vs nebula brightness
The final image below shows the brightest part of the nebula. At gain 300 and offset 65 you see a mean value of 544 ADU which compares to 96 ADU for the faintest part of the nebula and an adjacent background of 93 ADU.
The final piece of information pertains to the camera/chip specification and performance. The graphs below are from the ZWO website and clearly show as expected the more you increase the gain the read noise is lowered but unfortunately so is the full well maximum (the amount of electrons you can store in a pixel) and the lower the dynamic range, which for deep sky objects is a required.
So from this first piece of testing what have we learnt? Whilst there seems to be a good sense for increasing the gain and offset to help with the SNR especially between the background and the faintest part of the nebula, the increase in amp glow, decrease in dynamic range and reduction in the well count are all factors. Stacking as we will see, will undoubtably help the situation without necessarily setting a high gain. You can see why people say use Unity Gain, so the setting where 1 electron on the sensor = 1 ADU potentially gives the best result from a tradeoff point of view.
I have spend over 4 hours today reading about the Gain and Offset settings for the ZWO ASI1600mm Pro Cooled mono CMOS camera I have on the back of the 12″ Officina Stellare 305 RiDK f/7/9 telescope.
ZWO ASI1600mm Pro Cooled on Officina Stellare 305 RiDK
In particular the posts by Jon Rista and the images with a similar setup from Glen Newell have led me to a handful of setting I will now try from my location and on M76, the Little Dumbbell planetary nebula that I had started to image recently. I must also comment that Kayron Mercieca also had some useful information pertaining to testing your camera and OTA imaging train for exposure times. See link here
Discussion on exposure times and setting – Cloud Nights
So I have already taken a set of images on the 8th October, 14 of them and they were at a Gain and Offset of 10 (I believe these settings are less than perfect) and an exposure of 1200s, so 20mins through an Astrodon OIII narrowband filter. My location is on a good night in the Orange Zone as per the charts borrowed from the forum discussions and when referring to broadband imaging. For narrow band as per my test here I am between the purple and blue zones.
Inspecting the original frames I took you can see slight amp glow from the right of the image, the background has a median of 10 ADU at 12bits. None of the stars are saturated or clipped. The brightest star is 1,854 ADU our of a dynamic range of 0-4,095 ADU. The faintest nebula I can see is 11 ADU so just above the background and the brightest part of the nebula is 77 ADU.
M76 – 1 x 20min OIII Gain 10 Offset 10 – ASI1600mm Pro Cooled
So I will attempt to take a set of images at the following settings across 4 exposure times of 300s, 600s, 900s and 1200s at or after astronomical night at 20:56 onwards if the clouds hold off.
Gain 0 – Offset 10
Gain 75 – Offset 12
Gain 139 – Offset 21
Gain 200 – Offset 50
Gain 300 – Offset 50
Gain 300 – Offset 65
So after several false starts of broken cloud disrupting my ability to keep the dome open, I managed to grab the first 6 frames of 300s as above. Here is an animated GIF of all the images in order of Gain lowest to highest. (Click the image to animate or right mouse click and download)
In my next blog I will look at the analysis of the first 6 frames whilst I take the other frames to compare.
Tonight Bob and myself had a couple of things to achieve on the dome so that it would be ready for Autumn. As the Moon was out in full force, Bob decided to have a go at ironing out some more configuration bugs with guiding whilst I later in the night would test out the automated TPoint run.
Something I had not appreciated about an automated run was that instead of selecting bright stars, slewing and manually centering as you would when doing a non-automated Tpoint run, the automated run takes images of random or selected areas in the sky rather than centering on a star and then determine how far off it is from where it thought. Unlike a Closed Loop Slew that would take 2 images, one when it completes the initial slew and another when it has shifted to account for the error and plate solving to make sure it is now in the right place, the automated Tpoint just takes that single image then moves on, registering the error as it goes, building the model and applying the correcting to make the pointing better.
So at 23:27 Bob had finished attempting to setup guiding in PHD2 on for the QHY5 guide camera on the Talk 102. There wee still some problems, especially around a little trailing in 2-3 minute images. I suspect that the guider was being over aggressive in correcting in RA and possibly DEC causing the issue. Bob started to play with the parameters but decided to try again another night after reading the PHD2 manual.
Now for the automated TPointing run. We had to go in and setup The SkyX (TSX) so that it could control not only the dome and mount but also the camera on the back of the OS12″. Once that was done we setup the automated calibration run settings to find 10 targets evenly spread around the sky and avoiding the North Celestial Pole.
Target setup
What we did have a challenge with was the Moon, which being very bright does not lend itself well to being able to plate solve next to it with a large telescope, mainly due to light scatter within the tube and an ever increasing brightness in the background.
So the first major obstacle when we clicked start, was once it slewed to the first star field, plate solving there. This proved rather difficult to get working, about 1.5 hours of rather difficult! It kept failing to plate solve. So after reading the manual (RTFM) I realised that there was really only 1 parameter that needed to be changed to get this working and that was increasing the exposure.
TPoint in action
After changing this for 30s to 60s and then again to 120s the solving worked. Why? Well because the Signal to Noise Ration (SNR) was simply not high enough due to the background glow caused by a full Moon.
Target 5 acquired
Now the first target was solved the mount went on slewing, the dome turning and the camera imaging until I reached target 6 of 10 and then it failed again. However looking at the downloaded image it was not hard to see why, clearly the Moon was just off to one side.
Nearby Moon….cannot plat solve this!
So I skipped this target and carried on to complete the set. So with an initial 7 targets solved (a few others were near the Moon) that was enough for the mount to land on the target every time and each time the solving got quicker to the point of being sub second.
With the understanding of how to do an automated Tpoint firmly in the bag we decided to shut down the IMT3 for the night and await a cold dark evening after the clocks go back on 21st September to perform a large Tpoint run of around or possibly over 300 targets.
I find I notice some interesting things on the All Sky Camera, which is a USB 3 ZWO ASI120MC-S CMOS camera inside a purpose built casing and clear dome. Firstly I land up with beautiful clouds rolling past. I also noticed the light pollution as I mentioned in a previous post from the bathroom window upstairs. This image is when I had the camera on the ground by the observatory as I was testing the maximum length of powered USB I could get away with before data loss caused issues.
Bathroom light on
When the light is turned off it is noticeably darker.
Bathroom light off
Sometimes I get visitors to the camera.
Daytime visitor
and sometimes I unexpectedly capture a meteor 🙂
Raindrop, Clouds and Meteor
So it transpires I can use a single 3m powered USB cable to the USB hub, I cannot use 2 x 3m powered USB as that causes data loss and hangs and I cannot use a single unpowered cable either.
So I managed to go out and quickly bag a few images of M13 to test the travel scope on the night of the 1st to the 2nd September. It was relatively cool and clear. The main aim was could I take images that were not overexposed on stars whilst capturing the fainter stars at the same time. Also I wanted to make sure I could process an image too.
So all in I took 10 x 5 minute exposures but unfortunately I had not read the Skywatcher manual and had not locked up the focus tube. This meant that the first 3 frames were out of focus so I tightened the locking latch and then took the other 7.
On processing the image I noted the black (white) band to the top and right of the image where I had not switched off the setting for Overscan. I could not PixInsight to recognise it properly so I simply pre-processed the image and then cropped it out before processing.
Overscan area present
I managed to get Photometric Colour Calibration working which helped get the colour just right. I then processed in my usual way using the following workflow.
Apart from the various benefits of darker nights such as better sleeping patterns for humans alongside a bat friendly environment then the benefits for astronomers cannot be understated.
We use a Sky Quality Meter from Unihedron in order to measure the seeing conditions and record it in the long exposure deep sky objects we try to image.
Below is the graph for the entire night of 8/9th September 2019 and the effect of bathroom light close by can be observed at around 21:20. This clearly demonstrates how bad local light pollution can be. By 4:30am the astronomical darkness window had passed and the SQM was dropping.
The effect of the new street light policy at 1am is obvious as an increase from a SQM reading from 20.4 to a maximum of 20.59 is observed until 4am when the street light came back on again and the sky quality immediately drops.
This places the local area as bortle class 4 ( 21.69–20.49) and a long way from a rural setting (21.69-21.89) or even Kielder Water (21.88) which can only get worse with more housing developments and unnecessary outdoor lighting.
So although we are grateful for improvement in the local dark skies it would be great to see the lights staying off for longer in winter so we can attempt to get better images. Hopefully we can start to come close to appreciate what people saw before the intrusion of unnecessary artificial lights in our life bloated out the wonders of the night sky without having to resort to traveling to the top of La Palma.
