han59

The UCAC4 picked up fake star streaks, the UCAC3 didn't have. The USNO didn't show interest in cleaning the UCAC4. The UCAC5 was a release where they improved the star positions using Gaia DR1 but unfortunately they choose again a different format so I didn't bother using the UCAC5. All this is now superseded by Gaia dr2. All other star catalogues are now in principle obsolete. Stars don't have a designation anymore. You could identify stars using IAU style coordinate-based designation. If somebody is interested, I have also compiled a list of the missing brights stars in Gaia dr2. I checked up to magnitude 8 against Tycho2 but it was difficult. Han

It is an interesting experiment to try to use MS-Access for accessing millions of stars. I don't know what your trying to achieve, but by mapping, you should divide the celestial sky in area's and write a file for each section sorted in magnitude from bright to faint. Then you can fill a map in maybe a second or so even if you have 200 million stars on your hard disk. For all other queries you have to go through the whole database which will be time consuming. Dividing the celestial sphere can be also a challenge and worth a long study. To fill a star database, I found it is easier to extract them in CSV format from the Vizier server using a query rather then peeking in the original format. At least that is what I did for Gaia up to magnitude 18 and in steps of 0.1 magnitude. Han

I think to keep the size manageable, you can only use a lossy format like JPEG. But there is difference in quality of the compressors and most important a low compression setting to avoid too many artefacts. Compression factor 90 or 100%.

I have described the UCAC4 header record and decoding at: https://sourceforge.net/p/hnsky/code/ci/default/tree/hns_Usno.pas for program: https://sourceforge.net/projects/hnsky/ It is Object pascal, (lazarus/FPC), record length 78 bytes. Han

FYI, Both the HNSKY (planetarium program) and ASTAP (astrometric solver, FITS viewer, stacking) are now available for the Raspberry PI. I used an older version of the compiler for compiling HNSKY, so the menus don't look perfect but at least it works. See this as a ß version. The Tycho star catalog is included. You could add manually the star databases G16, G17 or G18 up to magnitude 18. See the HNSKY webpage. The CCDCIEL imaging program can use ASTAP for astrometric solving. The CDCCIEL program is also available for Raspberry PI (armhf). The ASTAP program with the included star databases will take about 500 mbytes disk space. So there is now more choice for the Raspberry PI: Planetarium programs: KSTARS, CDC, HNSKY Imaging software: KSTARS, CCDCIEL Astrometric solvers (Plate solvers): Astrometry.net, ASTAP See above software as ß versions. Feedback is welcome. Improvements will come. Han

FYI, the latest ASTAP versions (0.9.128) can do blind solving. Below a comparison of the solving time by Platesolve2 and ASTAP of a 10 seconds monochrome exposure (2328x1760) containing about 200 stars: Offset_____PlateSolve2____ASTAP 0.9.127 0°__________1.5 sec___________1.4 sec 2°________ 15 sec_____________1.5 sec 5°________122 sec_____________2 sec 10°_______535 sec_____________4 sec 30°__________________________18 sec 60°__________________________97 sec For this performance the search spiral was adapted to the sky sphere. Secondly the depth of the star database reading is adapted to match the number of stars in the image. ASTAP can be used as a Platesolve2 substitute. See instructions at: http://www.hnsky.org/astap.htm#platesolve2 Prior to this you can try the solving capabilities in the viewer Request are made for native support in SGP and APT but no firm confirmation up to now. Note that ASTAP is still a ß version and feedback is appreciated. It was developed as stacking program but the astrometric solving capabilities can be accessed using the command line. Note that the internal plate solver works best with raw unstretched and sharp images of sufficient resolution where stars can be very faint. Heavily stretched, very long exposures or photo shopped images are problematic. It requires minimum of about 30 stars. Images containing of a few hundred stars are ideal. For star rich images the detection limit is adapted to limit the number of stars detected. This will only work for unstretched images. In the latest version also binning prior to solving is available for large images above 3000 pixels wide. This will also improve signal to noise ratio. For very problematic saturated images Astrometry.net will do a better job. Han http://www.hnsky.org/

Does SGP keeps on trying or is SGP satisfied with the resulting position? When I remember well, you can set the target tolerance in SGP and number of retries. Reducing this tolerance will only help if SGP is happy with the achieved accurracy. Han

After analysing some images series you will know what HFR (or HFD:=HFR*2) you can achieve. In the zenith they will be better then at low altitudes. In general I like to keep all images and only throw away the real outliers caused by loss of tracking or clouds. So in some image series, all images good or maybe 5% is bad. If it is all running smooth the quality will be consistent. Sometimes the mount HEQ5 has a bad position or day and 50% is bad. Or I try to track on on a hot pixel. My telescope focal length is 580 mm. So seeing has not so much influence. For longer length the problems will increase. If you have a very good mount almost all images will be acceptable. The HFD achieved in my setup is 1.8 to 2.0, so lets say 1.9. This is reported by FITS grader as HFR at around 0.9 Outliers are images with a HFD of 2.3 or HFR of 1.1 So what I'm trying to say is that for deep sky imaging keep all images which have historical reasonable HFR or HFD value. Only skip the outliers in HFR/HFD or star count. You can sort on HFR/HFD by clicking on the top of the column. It is not like planetary imaging where you have abundant amount of images and are just looking for that short moment(s) of stable air and perfect seeing. The FITS grader is new for me, so I did some testing to compare it with my own program ASTAP with similar analyse/rename capabilities. This program work well and fast. The only major drawback is there is no viewer included and can’t be linked either. + Can include subfolders + Report and average, SD values + Fast - No viewer The HFR (Half flux radius) should 50% of the HFD (Half flux diameter) value. Compared with ASTAP, FITS Grader reports typical maybe 10% better HFR or HFD/2 values so better values then ASTAP. It can only read 16 bit files which is not a problem since these will produced by almost all image acquisition programs like SGP. The star detection routine behaves a little different for problematic images. Los of tracking, so streaks in the image are reported as an image with a high HFD but normal amount of stars. In ASTAP streak images can be detected by the low number of detected stars. Minor clouds in the image result in a low star count. In ASTAP the number of stars detected stay roughly the same but the background value as a third quality parameter is reported as abnormal high. The latest version of FITS grader is from 2012.

The development continuous. The latest ASTAP version 0.9.92 has a blink routine (for FITS files) to detect minor planets or nova or just make a video of a comet moving: Youtube demonstration: https://youtu.be/7cheLI-3ggQ At the moment the blink sequence can't be exported , but you could capture it by a screen capture program. So ASTAP has become more a software suite. The main functionalities are: - FITS viewer and manipulator including annotation of deep sky objects and stars. - Stacking program, blinker - Plate solver with two types of command line interfaces, remote accessible. Feedback is welcome Han The new blink tab:

Manual is fine. I did till 2 years ago. So your program automates camera control. Fully automated imaging has the advantage you can sleep while it is happening, focus is updated regularly and with plate solving in place, imaging series can continue the next clear night. For me the auto focus to compensate for temperature drift and plate solving are the big improvements. I still stay awake to review and change target. My typical exposure time and cooling temperature are pretty constant. As long it is not too bright like M31 center where it should be equal or less then 50 seconds, I stick to 200 seconds. It is just a number but I could also have taken 100 seconds. It is a compromise of lost time by downloading each image, percentage lost images due to guiding problems, data size and have enough images to recover from the 12 bit A/D resolution to something close to 16 bit by stacking. Gain is always at unity gain. so I don't have to update my darks and flat-darks/bias all the time and keep them for a few months. I see no real practical advantage of playing with the camera gain.

No. it is to set the target object RA,DEC position in a sequence line. I can't see in the video how you set the target position (RA,DEC) but that would a basic feature of a sequence unless you want to do it all manual. A sequence line should contain camera settings (exposure, binning, temperature.....) and the object position for mount (RA, DEC), guiding settings (exposure, ditter...), auto focuser settings (every .. th image, focus focus method). This automated sequencing will only work if you have plate solver in place to home in to the specified target position unless you have superb mount.

- No, that serves no purpose. The idea is to fill the (StarQuew) sequence with info from the planetarium program, so name, RA, DEC and orientation of the object to be imaged. StarQuew is then the client to the planetarium program server at port xxxx. At the moment, I don't know if planetarium programs can be controlled via INDI. - I'm not aware of an PHD2 INDI driver to control PHD2. PHD2 can be controlled as client of the PHD2 internal server at TCP/IP address 127.0.0.1, port 4400. Why would you need a X-server? The Linux version of PHD2 can use INDI to control mount and guiding camera. https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring

The link is useful for importing positions rather then typing them. If you want to image two objects, you will need a position in the middle or will need the position of a faint object, moving comet or just want to make an mosaic, the planetarium program can provide the positions. Have a look to interfacing of the acquisition programs as APT and CCDCIEL with CDC, HNSKY. APT can also talk with the C2A and SkytechX planetarium programs. Secondly a link to a plate-solved image or exporting the frame showing the dimensions and position can be exported to the planetarium program to see which fuzzies are on the image. PHD2 is pretty established. An Linux version is available. A link to this popular guiding program will be essential to many users. The planetarium program will most likely not use INDI as client but provided an own server interface. Same with PHD2. Planetarium server commands: https://www.ap-i.net/skychart/en/documentation/server_commands http://skytechx.eu/?page=skserver http://hnsky.org/help/uk/hnsky.htm#server An example of exporting an position:

Nice work. This looks promising. Now a server link to planetarium program(s), guide program and plate solver(s). Did I see a FITS preview function on the video? Han P.s. I lived a few years in Ealing as an expat. The Skies orange/red where not inviting to do astronomy. I unpacked my telescope only two times. http://www.hnsky.org

If your not in your normal environment it is always difficult. For me Windows user, Linux starts to work, but yesterday and today I spend most time on RDP and VNC. First I think Lubuntu or any flavour with LXDE is much faster then e.g. Ubuntu and Windows users will feel quicker at home. At the moment I use Lubuntu 18.04 For remote control from my house to garden shed, I went yesterday from xRDP to VNC, to Teamviewer, all failed! RDP worked but got a blank screen . Finally discovered that I had to give access to anybody in a config file . With RDP working, I noticed RDP opens a NEW session and I like to have the observatory screen and inside home the same, so I can walk outside control local the running programs. So RDP is not the solution. Finally I got Teamviewer working and that's for me the way to go. Then I was struggling with INDI drivers and found that USB-focus driver v0.9 works for me and not v1.0 It is an adventure, but I had similar problems of equal significance in Windows some time ago. If you have mastered the initial problems it will work reliable. Win10 behaviour and even Microsoft poking in Win7 makes me unhappy, so I'm slowly pushed to Linux. Han