han59

Manual specifies: Resolution of Aux. R.A./Dec. Axis Encoders1068 Counts/Rev., approx. 20 arc-minutes If this in range with the errors, then you can't get it better.

An other possibility is severe cone error ,https://www.youtube.com/watch?v=WatdQlPp22Y but that doesn't explain the error increases after the sync. I would check the communication equinox settings, switch of any modeling/correction in the mount if any and check the sync functionality using a planetarium program. Or simply hysteresis in the mount? What is the size of the error?

Mix up of J2000 or Mean position could explain small errors. An other possibility is wrong polar alignment of the RA axis.

Note that if it is not polar aligned correctly, it will miss the target. Thee RA axis should be pointing accurately to the celestial pole/polaris. So if your living 55 degrees north, the axis should be at 55 degrees elevation pointing north. Assuming you it uses an ASCOM driver to communicate with the mount, you could also tests if the syncing is working using a planetarium program. In planetarium program you can point to a star and request the mount to sync to that star position. After the sync the mount pointer should be at the star position.

Your method is good as the others. There are three ways to sync it: Unlock the scope, move it manually till the target star is in the finder and to lock it again is a quick way to get it aligned (from 20 or 30 degrees offset) in maybe 20 seconds without the requirement to sync is the mechanical way. You could use this method with only the mount and no camera or computer available. or Slew with the control buttons to the target star and sync to it in the planetarium program. (Planetarium program with scope control required) or Take an image, do the astrometric (plate) solving and sync the mount to the solution. (Camera, imaging program and solver required) All methods work. I use normally the last one but you need to be fully automated.

Note that the Moon can rise twice in one Earth rotation (23:56 minutes) due to it's own movement.

Assuming you have a Skywachter/celestron? mount, I do the following using 1 star alignment: 1) Assure the mount is polar aligned using the mount alignment scope or just visually. 2) Unlock the scope and point the telescope by hand to the celestial pole/Polaris. Lock again. 3) Power on the mount. The mount is now roughly aligned. 4) Slew using the planetarium program to a bright well know star/object. The scope should point to the object within maybe 10 degrees. Unlock the mount and center the scope by hand to the star using the finder scope and lock again (or use plate solving to sync)

Some thoughts of what I picked up from hobbyist nearby: 1) Backup channel to reboot the computer seems essential. So a power socket you can control via internet to reboot a frozen computer. 2) Local help if you remote access/control fails. The free version of teamviewer seems to work fine as long they don't classify you later as a commercial company due to a shared internet address.

The az gti is an AZIMUTH & ALTITUDE mount. Plate solving finds the position in RA & DEC. Somewhere the conversion from RA, DEC to AZ, ALT has to be done requiring the correct TIME, LATITUDE and LONGITUDE. You should check these last three factors.

Graeme, Many thanks for the sets. The image quality is good, much better then LCOGT. Especially the CC Com set was helpful to eliminate a bug in the statistics. Since the image field is small (0.35 degrees) it finds average about 8 Gaia stars up to magnitude 17 which are not saturated and have enough signal to noise ratio. With respect to variable stars in the field, my first idea was to eliminate them using statistics, but that doesn't work for long periods. The best solution would be to create a new Gaia star database without any star having variable flag. That requires some work I like to prospone to the future. First the program should work easy and reliable. Below the graph of CC Com using your data. Below a second graph of one weak star in the image demonstrating the stability of the measurement. There is not much data available about V734 Lyr. In the Gaia archive, see below it doesn't have a variable flag. So any new variable free star database has to wait till Gaia release dr3 or later. Han And this KP-Lyn using your data. choose files... Click to choose files

Using the three image set above, I'm happy about the software performance as long the stars are reasonable round. Some images are really challenging. The main remaining question for me is how good are the magnitude values. The program uses every Gaia star it can recognise in the image as reference and calculates the mean flux/magnitude value of typical 50 stars. Flux/magnitude outlier values are ignored using simple statistics. The only problem is that the database has a 0.1 magnitude resolution (earlier designed for compactness) but that's compensated by the number of reference stars used. Using an other public image test set it was able to detect a 20 mmag dip of Wasp-12b. You can see the OV-Lup exposure times in one of the columns. Just noted that the table is not sorted correctly on time, but that doesn't influence the graph. Han

@coatesg , Here a plot of OV Lup. This time I used the raws rather then the reduced/calibrated versions. The reduced versions contained partly negative values and my software could not work well with that. Furthermore some images are exposed with 20 second rather then 10 seconds. I could not process the R and B versions since my star database contains only V. Some FITS keywords in LCOGT files are non- standard like ccd temperature and if flat or dark are applied. Han

These test sets help to improve the program and remove some bugs. The best approach is first to binx2 all images. The oversampling and poor guiding (if any) is confusing the program. I also integrated funpack. Helen, I have not idea what this red star ASASSN-V J183347.59+162557.2 is, but below the data the program produces. @coatesg I will have a look to OV Lup. The program need to recognize the object as a star. This is a different setup then AstroimageJ? If its too oval, the program will assume it is a double star and ignore it. I'm interested in your data as well. Han

Bij relaxing for oval stars, I get useful data for V735 Lyr out of the images:

Hello Helen, I have V0735 Lyr series. Images are solved except one which is only noise. The guiding and focus was not always super. In some images the stars are pretty oval and my software doesn't always sync on the star V0735 Lyr. The star reaches an ADU level of about 8000 max But that is a good test case. I will work on it and report. Thanks again for the suggestion. Han

Thanks Helen. Looks good. Can unpack them using Funpack.exe. Can solve them (0.4 meter) telescope. Now I have to find images relevant to variable stars in the 385000 images archive....

At the moment the nights are short and bright and it is difficult for me to image variable stars. I'm working on a photometry extension of my freeware program and would be interested in existing set of images to test the program photometric capabilities . If anybody has an set an existing set of images which he/she could share that would be nice. The program has currently the following functionality: - Read/use FITS, DSLR raws and calibrate them using darks, flats & flat-darks. - Astrometric (plate) solving the images. - Detect the stars on each image and compares them with a Gaia star database in Johnson-V to determine a mean flux/magnitude relationship. This I call a photometric calibration. - Measure one star in the series and report the estimated magnitude against JD and HJD. - Export to a spreadsheet by select, copy & paste. The aim with the image set(s) is to test the accuracy of the measured magnitude, check the HJD calculation against existing measurements and to detect possible bugs or ways to improve. The program doesn't use BAA or AAVSO reference stars, just Gaia. Han

With respect to timing an object in a stacked image, If the stacking program keeps a record of the start exposure times and fills the final stack with the correct earliest start exposure time and correct summed exposure time this "timing problem" should be no problem. I assume an equivalent solution would be to draw a trend through an abundant amount of measurements. All according the same principle noise reduces with more samples. Just noted the time is geocentric. Is helio-centric not more used?

Looks good. I noticed that the variation (noise) in the measurement values is about 0.02 = 20 mmag. That I see also in my measurements. That seems to be the minimum for observations just above sea level. Does it ever get better then this? Han

Is it not time to use the Gaia data? The accuracy is unprecedented: https://gea.esac.esa...mentation/GDR2/ With the G, Grp (red), Grp (blue) you can calculate the Johnson-V magnitude as specified in the Gaia documentation. This is already done and available up to magnitude 17 in CDC, HNSKY and ASTAP programs. -- Han

There are a few variable stars with a very short cycle time. A very nice one is V1209 Her. This star varies around 0.7 magnitude in 74 minutes. I found this one in the GCVS, the General Catalog or Variable Stars. See also: https://www.aavso.org/vsx/index.php?view=detail.top&oid=150287 To test my new automatic magnitude analysis routine, I imaged continuously for of a little more then 2 hours and each exposure was 200 seconds. The resulting images were automatically analysed by ASTAP v0.9.222c and compared with the internal Gaia database (Johnson-V version). The final results were exported to Excel with the result below. Calibration and selection of reference stars was fully automatic. The exposure time was a little long and the star was almost saturated. The measured period is approximately 73 minutes, which matches very nice with the catalog data. The measured variation of about 0.7 magnitudes is also the same. The conditions were particularly poor. Several cloud veils. You can see that in the background values of the FITS files. Still a good result. The new photometry routine is promising. -- Han

Note that there is a CCDCiel 64 bit and 32 bit version. Some ASCOM drivers are only 32 bit and won't work with CCDCiel 64 bit. In case you have any driver/ascom problem, uninstall the CCDCiel 64 bit and install the CCDCiel 32 bit version.

The club member has measured the distance and it was as required. The plate solving came up with the following image dimensions: -Without extender at F5: 2.07 x 1.41 degree. -With extender 1.29 x 0.88 degree. The magnification is then 2.07 / 1.29 =1.6047. If the back focus distance was wrong, the magnification would be higher or lower then 1.6 The answer of Takahashi demotivated us to continue searching for a solution. Yes it would be good if an other user could confirm our findings or bring new insight. Han

Your page indicates a Takahashi FSQ130ED The camera you use a QSI 6120 has a sensor size 13.2mm x 8.8mm. This is an diameter 15.9 mm. Yes that will work better then a 21.6 mm2 sensor diameter we have. Takahashi advertises with 44 mm circle diameter. We have checked the back focus distance with plate solving and came to a calculated focal ratio of F8.02 assuming the telescope is F5. So the back focus distance is correct. Attached an an F5 and F8 image. Zoom in to the corners.