- My experience with the Starizona Landing Pad
- A quick Review of the MIGHTY MAX 12V 100AH BATTERY
- Nexus II Review
- New Moon Telescopes 20”F/3.3 Review
- FIELD TEST OF THE BAADER MAXBRIGHT® II BINOVIEWER
- My Experience using SkyWatch for the Alphea All Sky Camera from Alcor Systems
- Astroart 7 - A Review and "How To" (Part 1)
- My experience using two 80-millimeter long-focus refractors
- GSO 8-inch TRUE CASSEGRAIN
- Celestron Regal 65ED M2
- Review: The Vixen FL55ss
- PrimaLuceLab Eagle Review
- interstellarum Deep Sky Guide Desk Edition
- Chronicling the Golden Age of Astronomy: A History of Visual Observing from...
- Omegon Mini Track LX2 Review
CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.
My Experience using SkyWatch for the Alphea All Sky Camera from Alcor Systems
Discuss this article in our forums
I love watching my own night sky unfold in real-time with an all sky camera. It has saved me from trying to figure out what was going wrong with my autoguiding when astroimaging. There it is, right in front of me, faint cirrus clouds drifting over my target playing havoc with my autoguider. It is also fun for capturing shooting stars.
All sky cameras are not for everyone. The most common comment I get is why don’t you just go out and look up? But the same comment applies to astroimagers: why are you taking pictures of an object that I can get from Hubble Space Telescope or dozens of other web sites? The answer: it’s fun!
I ordered the Alphea All Sky Camera through Hyperion-Astronomy on 13 September 2019. It’s not an inexpensive camera: $2,000 without the stand. I received an email indicating that it would take 6 weeks until it was shipped. When I reviewed my receipt, it did not have a packing slip or a proforma invoice listing the camera I purchased - just a thank you. I received the camera on 30 October 2019.
As I opened the box, it felt like I was opening someone's return item from Amazon that did not have the original packaging. It was packed well enough, but it consisted of used packaging and pieces of left-over boxes, padding and such. The camera arrived with no packing slip in the shipping box and there was no indication of which camera model I received. Surprisingly, there are no markings on the camera to indicate the model. I wrote to Hyperion but did not receive an answer. So, I referred back to my credit card statement, and based upon cost, I should have received the Alphea 6CL. Installation proved this to be the case.
The Alphea 6CL contains a ZWO ASI178MC, 14 bit CMOS color camera based on the Sony 1/1.8" CMOS IMX178. It uses a 1/2" 1.55mm focal length, IR MP, 3096 x 2080 pixels wide angle lens with 4.5 Million pixels. The field of view is 180° x 180° providing 3.3 arcmin/pix. The exposure range is excellent at 32 ms – 1000 s. The Sony chip environmental specification calls for working temperature of -5°C - 45°C and working relative humidity: 20% - 80%. However, with Alphea’s watertight and heated enclosure, the camera can operate from -40°C to +45°C and presumably in a very wide range of humidity.
Invariably the Alphea SkyWatch software (not to be confused with SkyWatcher – maker of telescopes, mounts and tripods) will be compared to the free AllSkyEye software developed by Michael Poelzl. I had previously used the StarLight Xpress Oculus Camera with the AllSkyEye software and found AllSkyEye to be much more versatile than the Oculus software. AllSkyEye has the limitation of requiring that you compute the transfer function that maps stellar coordinates into the cameras distorted image. So, my goal was to upgrade to a color camera with better specs.
Mounting the camera.
I did not purchase the optional stand for the camera because it was not clear how this stand is installed to a pole and how it was better than using hose clamps, and not least, how it was worth almost $500. Instead I used an adjustable metal hose clamp strap to attach the camera to a steel fence pole embedded in a concrete footing. The camera is about 30 feet from my observatory with two cables, one USB and one 24-volt power supply, pulled through a 1.25" PVC Schedule 80 conduit into my observatory. Don’t try using a smaller conduit as the USB cable has large embedded USB extender that must also fit.
I mounted the Alphea in such a way that I could align the imaging frame to the orientation I expected would feel comfortable to me. I later found this wasn’t really necessary (I’ll come back to this). So, I set a steel post in concrete and made it vertical using a Post and Pipe level, tightened the hose clamp, made sure the connectors were secure and ran the SkyWatch application. For such as expensive camera, I was surprised that a bubble level was not installed next to the camera. In the picture below, the Alphea AllSkyCamera is on the right and a Boltwood cloud sensor installed on the left.
SkyWatch Software Installation
The computer I used for my interactions with the Alphea and Skywatch software was on a Dell Precision Tower 3420 with Core i7-6700 at 3.4 GHz, 32 GB RAM on a 64-bit Windows 10. A Dell S2817Q display was configured at 3840 x 2160 resolution.
A note on my style: I refer to specific parts of the software (tab names, window titles, etc.) using its exact words and bold the text. Popup messages I received or quotes from emails are italicized to distinguish from normal text.
The SkyWatch software is sophisticated. For this review, I had access to version 18.104.22.168. You have access to many technical parameters that may require use of internet searches to fully understand. I quickly got the impression that SkyWatch is a work in progress with very incomplete documentation and mediocre, but promising, user interface. During installation, Xvid MPEG-4 Codec and ZWO ASI DirectShow drivers were installed. If you already have a ZWO camera, be alert that you don’t accidentally install an old driver over a more recent driver.
After installing the software, I received the error message "ASI camera init failure" and a statement that my camera was not authorized. After emailing Hyperion, I got an email from the developer. Apparently, I did not select the appropriate software. Since I had no direction from the seller, I downloaded what I thought was applicable. An email from the developer Cyril Cavadore in France resolved this issue, but this copy protection issue did revisit me. In brief, this is software copy protection. More on this later.
As I was reading the manual, I noticed a minor discrepancy with the documentation. The connectors differed from those shown in the manual.
With the copy protection issue resolved, the software immediately will attempt to connect to the camera. If it cannot connect, you will receive an error message "ASIcamera init. failure noASI-ZWO camera found, check cables." More information on the camera initialization is provided in a scrolling log / message text box which unloads itself after 20 seconds. Curiously if the Hide button is not clicked right away, it will not work later, nor does clicking the small X in the upper right close the Messages windows. You can make the log window visible again by clicking on the Misc menu.
Next you need to click on the Camera Setup pull down menu item which provides you the opportunity to find and select your camera.
The next configuration menu is General Software setup. Here you enter your location's latitude and longitude. This is critically important if you enable the star overlay option (discussed later).
All your settings are stored in this folder
Make a backup copy of this folder when you get things working.
Image Storage Considerations
Next you need to select or enter your Base Folder for all image recording. A new subfolder is created at noon every day.
SkyWatch software allows you to manage the storage size of all your images from the control panel. Under the Recording tab, you can select various intervals, such as every 3 or 7 days etc., for automatically deleting your images.
SkyWatch can create a lot of images and consume lots of disk space. A jpg image is approximately 2 megabytes and you could get about 3,000 jpg files in one night. The CPA image runs about 20 to 30 megabytes; a FITS image is about the same size. The “unfolded” image file is about 1 megabyte. Depending upon the value of the minimum interval between exposures a night’s folder could easily contain 2 - 4 images of each format from sunset to sunrise. Finally, if you allow SkyWatch to create AVI’s, a full night’s video runs about 400 to 1,000 megabytes. You can manage the AVI size by changing the AVI file scale, a quality factor that you select from 25%, 50% or 100% on the General Software setup window. Changing the AVI file scale to 50% reduced my AVI to 150 GB. The AVI file scale option is not persistent.
Of note, the SkyWatch software has a different approach than Oculus and AllSkyEye for generating AVI videos. You can select how often an AVI file is created, such as every 60 minutes or other time interval. This provides a series of shorter and more manageable videos.
With these many large files constantly banging on my hard drive, I knew this would shorten the lifetime of my SSD as an SSD has a limited number of read/write cycles compared to magnetic disk hard drive. To avoid this potential problem, I attached a portable 1 TB USB drive to save all the images.
There is a setting on Image grab control on the General Software setup window to select the minimum interval between exposures. Your minimum interval is limited to 5 seconds, so you will always have at least a 5 second gap in your image sequence. By default, there is a setting on the Camera tab that specifies not more than 1 image per minute. Useful if you want images at a constant interval. If you are trying to catch meteors, you will have time gaps. But then on the software General Software setup window, there is a checkbox that enables: During night minimize time between exposures. I have not seen the impact of this feature yet. However, I did analyze how frequently SkyWatch was capturing images. The diagram below shows the duration of 3 image exposures along a timeline. Although each exposure was approximately 5 seconds long, there was a gap of 26 and 33 seconds between exposures respectively.
In the Software Setup window there is a setting in the Misc frame that allows the user to disable the log fie.
The expectation was by turning off the log file the slow disk writes would be eliminated and thereby improve the performance. Upon disabling the log, I did not detect any significant change in the gap size.
Displaying Weather Conditions.
If you have either a Boltwood Cloud Sensor or Lacrosse weather station, you can direct SkyWatch to read your weather data text file. The weather data will appear in the upper right corner in “cartridges” of the saved image only, not on the screen. Neither the font type nor size are customizable.
Taking images and video.
After completing the general configuration options, the main SkyWatch window presented does not have a tool bar with "Take Photo" or "Stop/Pause Photo" button. So, you will need to dig deeper into the control panel.
If all goes well, the camera will start exposing images immediately. If it works, then you will immediately see an image placed on your main screen under the first tab called appropriately enough Image. The Image tab is for displaying only the most recent image of your session. You cannot open previous images or videos nor can you open images and videos previous night sessions.
Even though you see an image, it may not be saved. You must first set the save folder (under Software options) and then you must navigate to the Recording tab on the Control Panel and select Save all images. (More on this later.) If you do not see this Recording tab, you will need to click on the tiny scroll button in the upper right of the control panel to bring more tabs into view.
The default image format is FITS and CPA. To save in jpg format you need to navigate to the Recording tab and select enable recording.
CPA is a Prism specific image format. If you don’t use the Prism software, you can check a box on the software setup that will prevent CPA files from being saved:
I had expected the equivalent of "VCR" control buttons, but no control is available from the image display. You cannot pause or continue the imaging nor display previous images. You can reduce the image scale, so it does not dominate your entire screen. I typically run the Zoom level at 1/4, just enough so that I can keep an eye of the sky. It would be nice if the mouse wheel controlled the zoom magnification.
One consequence of the SkyWatch software continuously taking photos (as implemented) is the frustrating lag in refreshing the parameters you enter. This lag is different than the previously mentioned minimum interval between exposures, which is 5 seconds. The Control Panel does away with an “Apply” button, so all changes get queued. For example, when I wanted to enter “1520” as the X center coordinate of the image on the Overlay tab, after I had just entered the first digit “1”, SkyWatch implemented a pixel radius of “1”. Easily fixed but annoying. Upon inspection of the log file, the performance lag might be due to the large amount of writing to the log. Each exposure had at least 50 records recorded to the log file. Writing to a log file so frequently will drag any program performance down. I get the impression this version of SkyWatch is a debug version.
Only in the displayed image, the camera settings are provided at the lower left of the image in a status bar. As depicted in the following graphic, it shows: 1) date, 2) local time 3) exposure sequence number, 4) exposure time and 5) the autoexposure gain. I found the gain cannot be adjusted in real time. If it is adjusted, it is not updated on the status bar. But note, unless you select “Put local date in jpg image” on the Recording tab, the date-time written to your jpg will be in universal time!
Frustratingly, the image exposure time is not recorded on the
image itself, nor in the image file’s metadata properties, nor, as in some
other applications encoded in the file name. It is only provided on the status
bar as indicated above. As you review your previous night’s images, you can
only determine an image’s exposure time by searching through the vast log file.
To find the exposure, you need to search the log file for the exposure sequence
number on a record that looks like this:
##### End Procedure-> 2.567 s (exposure #8719).
A subtle feature to be aware of is on the Camera tab in the settings frame provided below.
When automatic exposure time is checked, the maximum exposure for the camera is explicitly limited to the Exp. Max setting. I had thought this was for when you disabled the automatic exposure setting.
To aid calibration, SkyWatch permits the user to click within the image and obtain azimuth and altitude of the click position as shown in the status bar. For example, if you see M42 on the image and you click on M42, then the horizon coordinates are displayed in the status box identified by its altitude H= 24.3° and Azimuth AZ=13.5°. This can provide astroimagers an easy view of an object’s altitude for planning images. More on this later.
24 Hour follow up
The second tab, to the right of the Image tab on the main window, is the 24 hour follow up tab. It displays how the sky has changed in a single glance over 24 hours. The 24 hour follow up tab stitches together a thin vertical slice of every image recorded, that run through the camera’s zenith, and concatenates each image so as to form a timeline. Here is a 24 hour follow up image for about 14 hours from early evening to dawn. The bright white spot is the full moon.
Note in the status bar of the above picture, I circled a field called Date. The date field shows the time of the slice your cursor is over. A schematic showing how an image slice is mapped onto the “24 hour Follow up” is shown below.
These 24 hour follow up images are saved to a subfolder named “Slice”.
Finally, there can be a third tab "Horizon unwrap" if you have checked “Enable image unwrap” on the software settings window.
Unwrapping is the SkyWatch term for dewarping. Dewarping refers to the process of perspective correction of an image, which reverses the effects of the geometric distortions caused by the AllSkyCamera lens. Dewarping provides a "normal" view of an otherwise distorted image. The SkyWatch Unwrap does not reverse all the distortion.
The control panel contains lots of settings and system status. The Control Panel cannot be closed, its position is not saved between SkyWatch sessions, and, more importantly it cannot be resized. The latter becomes a real problem in locating settings.
The Control Panel is a non-resizable window that consists of 8 horizontally scrolling tabs of which only 2 to 3 tabs may be visible at a given time depending on the width of the tab’s text.
- System Status
- Overlay grid
- Cloud coverage
The Control Panel is set to always be on top of all other windows and always positions itself on the right side of my screen. This always on top mode is annoying when I am working with other applications as I must constantly move it out of my way.
You can have SkyWatch show where your telescope (and five more scopes!) is pointing as an overlay on each image. SkyWatch reads a text file generated by the author’s Prism planetarium software. This is specified under the main Options, setup menu.
It cannot read the functionally equivalent text file generated by Software Bisque’s TheSkyX (TSX). I have both software applications, and I wanted to also obtain the telescope position from TSX as well. Consequently, I needed to write a small reformatting program that takes the TSX coordinate text file and converts it into the Prism coordinate text file. The Prism text file needs 1) modified Julian date (JD) = JD − 2415020. 2) coordinates specified in radians. TSX does not output any type of modified Julian date. It is odd for this to be a requirement and not assume the coordinates are for the current time.
The program is straightforward, except for the need to generate the weird Julian date format, called the Dublin Modified Julian Date (See Wikipedia).
SkyWatch can accurately display various named stars and display constellation line drawings. However, to do this takes patience. The camera must be accurately pointed or referenced to north, must be perfectly vertical and the center of the image must accurately coincide with the zenith.
In the control panel, Overlay tab, I ticked the check boxes for Display overlay grid. I tried to move the overlay grid by using the mouse and shift key but found it very frustrating. The horizon circle just flies to various part of the image when I try to move it a small amount. Since the images are 3096 x 2080, the coordinates of the image center should be pretty close to (1548, 1040). I then sized the radius to fit the horizon circle until the star labels matched the real stars in the image. This was my starting reference point.
To obtain my north bearing during daylight I used my iPhone with the Theodolite application. This app overlays the true compass direction on your image. I moved about 10 feet behind the Alphea while facing north. I snapped the image show below. I could now match the compass direction to the SkyWatch image.
To improve this rough alignment, the manual indicates I must accurately find the center of the image using a relatively bright star transit.
The Installation and User manual provides this procedure for calibrating:
1. Identify a star of magnitude 0 to 3 when it passes very close to the zenith, +/‐ 2° from the zenith.
2. Force a fixed exposure time of 5 seconds to 10 seconds using the Camera tab in the control panel, that is, uncheck “Automatic exposure time”.
3. On the “Overlay Grid” tab, check "Display overlay grid” and below this check “Only horizon”. Now click "Show main objects".
4. Find the star that passes nearby zenith and move the cross indicating zenith towards it.
5. Change “X center (pixels)” and “Y center (pixels)” figures so that the cross’s position matches with the star.
Note in Step 5, the cross position is only visible in the near real-time image and not on the generated image files. To identify the appropriate star, I knew I would need to find a zenith transiting star with a declination equal to my latitude. Given that my latitude is almost exactly 33° North, I identified all the stars between 32° to 34° North declination. Using the Yale Bright Star Catalog (Yale BSC), I sorted the catalog on declination. I found 6 stars with an apparent magnitude 4 < StarMag < 3 and no brighter stars. The star’s declination is a measure of the error distance from my true zenith.
ν Uma, Alula Borealis
β Lyra, Sheliak
ε Cyg, Gienah
ο Per, Atik
I used TheSkyX to determine the precise time of culmination for February 11. My two best stars to measure their zenith transit for this time of year appeared to be Alula Borealis and θ Gemini. Atik transits too soon after sunset at 17:26. Then there was the old gibbous moon to consider as it rose at 8:30 in the evening. To my surprise, I found that at 1:44 in the morning, the moon, although very bright, a 3.5 magnitude star was easily visible.
My first approach was to wait patiently for the time of culmination and move the cursor over the culminating star and transcribe the pixel coordinates of the center image. Then I realized that I did not need to do this. I can simply open the jpg image after a night’s run and identify the image file’s date-time corresponding to the star’s culmination through the zenith. Then using a graphics program, such as Microsoft Paint, I can easily read the pixel coordinates in the status bar.
Disappointingly, that gets me ONLY in the ballpark! I found that the accuracy required is at the single pixel level and the north bearing must be down to the tenth of a degree. From the θ Gemini transit, I measured the pixel coordinates of the image center at (x, y) = (1510, 1089). Again, I knew this was only an approximation. At transit, θ Gemini’s altitude was 89° 2’ 17”. At the camera’s 3.3 arcmin per pixel image scale, that is about 20 pixels away. I resigned to painstakingly altering all 4 coordinates to obtain a better estimation of the parameters at (x, y, radius, north bearing) (1513, 998, 985,253.2).
I knew I’d get better overall results if I created a set of dark frames. As noted in the manual,
“In the case of color camera these hot pixels turns into colored dot with showing pure color (blue, red or green) that affect strongly image quality… It is therefore essential to correct these hot pixels using an “dark" master frame, and possibly complete the task with a list of pixels to fix.” [sic]
I put on hold the star calibration procedure and got about the task of creating a dark master.
I live in a suburban Bortle 5 - 4.5 where I can frequently obtain 19.8 <= SQM <= 20.8 Mag /Sq Arcsec. (Pretty good for suburbia but not great). The manual recommends an exposure of 30 seconds. It also indicates one should choose the largest gain that is used during the night. I selected 11 darks for the median combine. The outside temperature was 14.8°C or approximately 15°C. Since the dark frame master is valid for +/- 5°C the I can use this dark master for temperatures in the range of 10°C to 20°C.
Upon completing the 11 dark frames I received the following message:
How could the file format change? Not knowing what this error really indicates, I changed the zoom to 1 from ½. That did not work. I next checked Save all images as CPA or FITS. That did not work. So now comes again the issue of support.
Support was of no help. The replies took days to receive and were mostly short and unhelpful, and generally dismissive. I found through trial and error, that I needed to check off the two boxes under the Save Images on the Recording tab:
Now I successfully obtained a dark master image. The dark frame master was named “dark_UTC_2020-01-19-02h02m06s.cpa” with the date and time encoded in the file name but not the temperature of the dark frame nor exposure length.
To understand it better, I opened the dark frame in Prism and saved the dark frame as a standard Fits file and inspected the Fits header. It shows the image was taken at 24.6°C and not the outside temperature of 14.1°C. It is clear that with the dew heater on, the chip is kept relatively toasty.
The manual indicates that the SkyWatch software will choose the appropriate dark master. I wonder how it can properly choose the master dark if the chip temperature is not encoded in the file metadata but only the outside temperature! Does this mean I should only use the master dark without the dew heater so that the ship temperature is close to the outside temperature?
Now for a surprise. In the early morning I decided to take another set of darks with the dew heater disabled. Upon repeating the dark frame generation process, the “Error on image set” resurfaced. Very frustrating.
The Alphea has dome heating resistors that can prevent significant amounts of dew from forming on the acrylic dome. The dome heater must be manually turned on (under the Options menu) and only runs when SkyWatch is running. If you forget you will be reminded when you see this and get an entire night’s images ruined:
The dome heating is not sufficient to deice the dome. If you need deicing capability and if you have the budget, upgrade to the OMEA or EUDA all sky cameras which have 40-watt heaters to defrost, defog or deice the camera dome.
If you keep the Dome Heating Control window open, then you can monitor the dome temperature in a graph. The labels of the x-axis of the graph are a bit unusual. For example, “14/01 08” refers to the 14th day of the month 01 (January) at 8 am. As you can imagine, the dome temperature is significantly hotter than the outside air by at least 10 C. One usability issue I found with the Dome Heating Control graph is that it takes up a lot of screen real estate and cannot be resized or minimized, although it can be hidden. You will not lose the graphing data if you click the “hide” button.
Enabling the Dew heating setting is not persistent. You must re-enable each time you start SkyWatch – if that’s what you want and generally, I think you would.
Looking at the temperature-humidity-dew point chart shown below, the Alphea operated through 96% humidity (light green line in the chart below) with the temperature and dew point less than a degree apart.
Here’s what the sky actually looked like and with no dew on the dome.
Unlike the oculus software from Starlight Xpress, SkyWatch (and AllSkyEye) computes the best exposure. You still have the option to select fixed exposures. You are provided the option as to which part of the image it uses for its calculation. I have set this option, Gain/Exposure Computation method to a 512 x 512 square centered on the zenith.
The below image shows three consecutive images of about 14 seconds each stitched together for easy comparison using the 512 square autoexposure setting. This pattern repeats.
I wrote Cyril and got this answer after a couple of days: “You have to put the overlay circle aligned to the image and use it to compute exposure time.” Aligned how? This was not helpful as I had already had the stars aligned reasonably well on the grid overlay. “The area used for auto exposure computation, is displayed in red in the image of the sky.” Now where is that red circle? There is no “display red circle” button. After pulling my hair out trying to find the red circle, I stumbled across the trick to seeing the red circle:
On the Camera tab in the Control Panel, I changed the selection and then changed back to Circular Fisheye and then clicked the image and waited. It does not show up immediately but only on the next exposure. And the circle stays there for 2 images and disappears.
This red circle is adjusted from the overlay grid by changing the image center and horizon grid radius. This is confusing in that the red circular exposure calculation area is the same as the overlay grid. Yet the controls move both together.
I found no solution to this autoexposure problem but have found that the autoexposure does settle down after about an hour after sunset. This issue needs further investigation.
An interesting feature is the Magnitude map. Under the Measurement tab of the control panel, if you check Display image as magnitude per arcsec2, then a new tab appears on the main window as shown below. The Magnitude Map image shown below is not calibrated. To use this properly there are parameters that must be specified and left for the future. Note, no Magnitude Map jpg image file is saved.
SkyWatch has implemented a star counting routine that can be used as a metric for a clear sky. This option is located on the last tab in the Control Panel and named Cloud Coverage. I made sure my dark master was enabled along with automatic hot pixel rejection (on Camera tab). The Cloud Coverage feature will count the stars in an image and apply user defined thresholds to determine clear vs. cloudy sky.
The data it obtains is supposed to be exported to text file which is “CloudSensor II Boltwood” compliant. The manual says, “The software output this data either into a text file or uses a COM interface that can be used by other any software.” But where is the filename and folder specified?
I could never find such a file. However, I did find a file entitled “StarList.csv” and StarExtract.cpa placed into a subfolder named “StarExtract” of the same root folder as specified in the software setup window.
The snapshot of this data file displays the x and y pixel coordinates of each star it identified along with a flux measurement. The flux measurements ranged from 23 to 6,468,195.
When this option is enabled, you image is littered with red squares identifying the stars it found along with two coordinates.
A closeup on the star Procyon is shown below and is labeled with 2.9 and 616,699. The later number corresponds to the flux identified in the csv file, but it is unclear what the first coordinate refers to.
The Cloud Coverage tab indicated there were 6,126 stars identified. The CSV file showed 6,163 records in total. When sorted the file by flux, there were indeed 6,036 stars above the “Mid overcast star threshold number” of 100.
I experimented with uploading SkyWatch images to my Weather Underground web site (wunderground.com). The FTP setup is found on the main window under the Options menu.
I configured the FTP options as shown below except that the jpg compression was originally left on the default 100%. FTP configuration was straightforward using the settings provided by wunderground. I then enabled the image transfer upload to wunderground.com.
SkyWatch does not explicitly alert you to the success or
failure of the upload (and there is no “test” button). I opened the FTP log
file found at …Documents\skywatch\FTPLog and
the log showed "Quota exceeded:". I saw it tried uploading a 2 MB
file. I reviewed the images SkyWatch uses stores for upload at
The published Weather Underground file limitation is 150 KB, but I have FTP'd files of approximately 500K with no problem. By changing the jpg compression to 35% the uploads went fine. As shown below, the SkyWatch’s FTP upload worked beautifully.
One drawback is that Skywatch uploads both the normal image and the 24 hour followup slice. When wunderground creates a video from your uploads, the video is interrupted with the 24 hour followup images.
There is no user support forum. The only support is obtained by directly emailing the developer at alcor-system.com. On January 5th I emailed the developer with several questions. With no answer, on January 7th I emailed the vendor Hyperion-astronomy and forwarded my email to the developer describing my new problem with creating dark frames. Shortly thereafter I got the reply “I will do my best to get you all the answers you need. I will be in touch”. I got an unhelpful response on January 11th which told me to restart my computer.
The two main problems I was having 1) I could not resolve the error obtained when taking dark frames, and 2) the SkyWatch software popped up an error message saying I was no longer authorized to use the software/camera. I sent an email to the developer entitled “please authorize” and his response was “total nonsense for us” and “We have no reasons to do that, I'm sorry to say this is paranoiac.”[sic] Needless to say, this was neither helpful nor conducive to civil discourse.
A second issue occurred when I connected my ZWO ASI 290MM Mini planetary camera to my Planewave telescope. I use the ASICAP ZWO software for the 290MM mini camera. I then started up the SkyWatch software and SkyWatch apparently became confused and stated “The camera (with serial number 000000) is not registered into the list of authorized camera to run this software, please contact email@example.com!”. This is part of their copy protection. The user cannot just enter a software license key. The camera serial number [is used] to authenticate SkyWatch software. As the developer told me “This is to avoid other/unknowns to use our software as a free software to run DIY all-sky cameras.”
I re-downloaded the software, uninstalled all the SkyWatch, ZWO and Xvid software and then rebooted and reinstalled all the software. This did not work, and I repeated the process only to see the problem persisted. I shut the computer down and removed the camera. The next evening, I booted up the computer and launched SkyWatch and all was well.
I have heard anecdotally that ZWO device drivers for different ZWO cameras do not always play nice with each other. Perhaps this was the cause of the problem.
Camera link loss
Frequently I will experience several times throughout the night: “Skywatch: camera link loss” followed by a “Skywatch: camera restarted!” within 45 seconds. I have checked all the cable connections and they were well seated. Overall it does not interrupt the nights image generation very much.
Rescuing the Alphea
There is a solution to the poorly documented SkyWatch software. Use Michael Poelzl’s AllSkyEye! It connects easily with the ZWO ASI178MC camera, provides automatic exposure compensation, meteor detection, and star overlay. However, the star overlay still needs to evolve as the user is required to create the lens transfer functions to properly map the stars to the image.
I have experienced many software issues. One annoying issue arose when I minimized the Skywatch application: it disappeared without a minimized icon. Thinking it crashed, I restarted SkyWatch and got the message:
Upon checking the Task Manager, SkyWatch is listed as a Background Task and not an open application. I checked the image file folder and saw that the images were continuing. The only way to continue was to end the background task and restart SkyWatch.
The next issue (previously discussed under the Autoexposure section) pertains to the autoexposure algorithm not being sufficiently robust to minor light variations. There can be large variations in the average frame brightness as displayed in the Autoexposure section above.
Third but most important, the lack of user support is a showstopper. With software in such an immature state, software support in incredibly important. I would expect that if the developer does not have the time to answer user questions properly that a support forum should be established.
Fourth, I generally let the Alphea camera run day and night. At random times I get the message “exposure setup cannot be achieved”. Perhaps this is ZWO, perhaps not – I can’t tell.
As if that is not enough to discourage any user, after running for several hours occasionally the Control Panel looks like this:
It totally wipes out all controls in the control panel. All I can do is close the software and restart. Simultaneously, I get a similar message from the Xvid driver:
Apparently, something has gone wrong with the Xvid – SkyWatch interface.
After restarting the software, the imaging continues. I left the SkyWatch software alone in my observatory for several days. When I came back to check on it, I was presented with an access violation. No idea what happened.
As noted earlier under section titled “Playing Nice”, this could be more of an issue with ZWO drivers than SkyWatch.
Given the problems I’ve experienced with the SkyWatch software, I decided to uninstall the SkyWatch software including the settings folders. (Note I did not delete the registry section.)
I wondered if I incorrectly changed something that led to some of my problems. For instance, I expected that the overlay grid would have been calibrated such that the star labels displayed correctly once I accurately entered the camera’s latitude and longitude and the offset from north of the camera’s orientation. This is not the case as shown in the image below using SkyWatch’s default settings.
The default setup coordinates for the image center is 640 x 480 pixels with a radius of 625 pixels. The exposure time is set by the 512 x 512 square centered on the camera center. This is interesting in that the manual says Circular Fisheye should be checked for computing automatic exposure time.
Perhaps the most glaring missing feature is a tool bar. A toolbar provides easy access shortcuts to toggle frequently used features off and on. For example, toggling:
1. Image acquisition
2. Constellation lines
3. Overlay grid
4. Main objects
5. Recording jpgs
6. Recording video
Other desirable features include:
1. Edited professional user manual.
2. Videos in mp4 format.
3. Customizable width/color of constellation lines (They are too overwhelming for me).
4. Meteor detection
5. Customizable star list
6. Read and display SQM readings obtained from a SkyGlow text file.
7. Horizon grid overlay with more tick marks on the horizon for NE, ENE, etc
8. Continuous zoom within area of interest with the main window resizing with image, instead of only 2, 1, ½ , ¼ zoom factors.
9. Change constellation line drawing of figures: Sky & Telescope, Patrick Moore, Astronomy Magazine, etc.
10. Ability to save the Magnitude Map as a jpg image file.
11. Improve image processing to minimize the gap between exposures for meteor detection.
12. Allow user to select which type of jpg file to upload with FTP.
The Alphea 6CL AllSky Camera is a well-made ruggedized outdoor color camera with equally ruggedized connectors. There is no bubble level to aid vertical alignment. The Alphea camera is very expensive given the accompanying SkyWatch software is not reliable and the user interface not well thought out. The software has the feel of an explorative research project into what can be done with an AllSkyCam. The overall slow performance is unimpressive.
I discovered many bugs and quirks. It includes many features, which are not well documented. This along with almost non-existent user support makes for an expensive and frustrating AllSky Camera experience. Given the present state of the software, the user might want to consider AllSkyEye.
In summary, given all the issues I found with SkyWatch, I would still look forward to a significant software update because SkyWatch does show much promise.
About the author
Jim Lawler is a lifelong amateur astronomer. He was primarily a visual observer up until about 5 years ago. His primary visual instruments are an Obsession 25” f4.5 Dobsonian, a Celestron 8” Edge HD, and a 120 mm Coronado Solar telescope. He recently built an octagonal observatory with a 10’ Technical Innovations dome which houses a Planewave 14” f7.2 Corrected Dall-Kirkham telescope with a Planewave IRF-90 Integrated Hedrick Focuser and rotator, which reside on a Software Bisque Paramount MX+. He uses an SBIG STF-8300 cooled camera and autoguider. The observatory resides in Poway CA. Jim Lawler has a Masters Degree in Astrophysics from Virginia Polytechnic and State University and has worked in the defense industry since grad school.
- soldatispace and Gene3 like this