Well. Not trivial at least.
However: I plate solve my images, after downloading, with ASTAP. But I also use ASTAP for aligning in Ekos. Could not the same process that produce the correct fits headers in the later plate solve process be used in Ekos, as it is (at least as an option) the same program doing the plate solve?
I have now found out that VPhot looks for the field CD1_1 to determine whether an image is plate solved or not. And my images from Ekos does not contain this field.
Am I missing something, or is this the way it is supposed to be? Could I do something to make the field CD1_1 (along with the data and subsequent fields) appear in the header?
I've been struggling to make Ekos include my observer code (LMN) as Observer in the fits file headers. I have 2 problems with it:
The box for setting my name (when clicking the small person above the capture job list) asks for my first name and last name. But I don't want that, I just want "LMN". I think I have solved it by entering LMN for both first and second name, then deleting one of them.
Secondly, and this is the most important: even though I have set LMN as observer, the image files still say "Unknown". What am I missing here?
I have the same lines in my PHD2 guide log (using a G11 and Gemini 2). My guide speed is set to 0.5x, I am not sure if that is just default or what. At least, I do not think this has caused any problems... But there might be a point, as you say, in actually reporting the guide speed, I guess.
OK, thanks. That one is NOT recognized by VPhot as having WCS, The one with the fits header below is - that one is OK with VPhot. Is there a difference in the WSC-sections? (there are stuff added by AstroImageJ here that I don't understand).
SIMPLE = T / Created by ImageJ FITS_Writer
BITPIX = -32 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 3354 / length of data axis 1
NAXIS2 = 2529 / length of data axis 2
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
ROWORDER= 'TOP-DOWN' / Row Order
INSTRUME= 'Atik 383L' / CCD Name
TELESCOP= 'Losmandy Gemini' / Telescope name
OBSERVER= 'Unknown ' / Observer name
OBJECT = 'IY_Uma ' / Object name
EXPTIME = 6.000000E+02 / Total Exposure Time (s)
CCD-TEMP= -3.00E+01 / CCD Temperature (Celsius)
PIXSIZE1= 5.400000E+00 / Pixel Size 1 (microns)
PIXSIZE2= 5.400000E+00 / Pixel Size 2 (microns)
XBINNING= 1 / Binning factor in width
YBINNING= 1 / Binning factor in height
XPIXSZ = 5.400000E+00 / X binned pixel size in microns
YPIXSZ = 5.400000E+00 / Y binned pixel size in microns
FRAME = 'Light ' / Frame Type
IMAGETYP= 'Light Frame' / Frame Type
FILTER = 'V ' / Filter
FOCALLEN= 1.76E+03 / Focal Length (mm)
APTDIA = 2.79E+02 / Telescope diameter (mm)
SCALE = 6.329659E-01 / arcsecs per pixel
SITELAT = 55.5481 / geographic latitude of observatory
SITELONG= 13.3647 / geographic longitude of observatory
AIRMASS = 1.0024698847910976 / Target airmass at mid-exposure
OBJCTRA = '10 43 55.94' / Object J2000 RA in Hours
OBJCTDEC= '58 07 31.88' / Object J2000 DEC in Degrees
RA = 1.609831E+02 / Object J2000 RA in Degrees
DEC = 5.812552E+01 / Object J2000 DEC in Degrees
EQUINOX = 2000 / Equinox
CRVAL1 = 1.6098310369E+02 / CRVAL1
CRVAL2 = 5.8125522265E+01 / CRVAL1
RADECSYS= 'FK5 ' / RADECSYS
CTYPE1 = 'RA---TAN' / CTYPE1
CTYPE2 = 'DEC--TAN' / CTYPE2
CRPIX1 = 1.6770000000E+03 / CRPIX1
CRPIX2 = 1.2645000000E+03 / CRPIX2
SECPIX1 = 6.3296592027E-01 / SECPIX1
SECPIX2 = 6.3296592027E-01 / SECPIX2
CDELT1 = 1.7582386674E-04 / CDELT1
CDELT2 = 1.7582386674E-04 / CDELT2
CROTA1 = 8.7754800000E+01 / CROTA1
CROTA2 = 8.7754800000E+01 / CROTA2
DATE-OBS= '2021-02-14T23:42:41.269' / UTC start date of observation
COMMENT Generated by INDI
JD_SOBS = 2459260.487977639 / Julian Date at start of exposure
JD_UTC = 2459260.491449861 / Julian Date (UTC) at mid-exposure
HJD_UTC = 2459260.4953886443 / Heliocentric JD (UTC) at mid-exposure
BJD_UTC = 2459260.49622639 / Barycentric JD (TDB) at mid-exposure
ALT_OBJ = 85.97138249500703 / Target altitude at mid-exposure
AZ_OBJ = 49.891940098519115 / Target azimuth at mid-exposure
HA_OBJ = -0.38823878790103805 / Target hour angle at mid-exposure
ZD_OBJ = 4.028617504992965 / Target zenith distance at mid-exposure
RAOBJ2K = 10.732206666666666 / J2000 right ascension of target (hours)
DECOBJ2K= 58.12551944444444 / J2000 declination of target (degrees)
RA OBJ = 10.754719617321642 / EOD right ascension of target (hours)
DEC OBJ = 58.013652798461955 / EOD declination of target (degrees)
HISTORY Previous Filename = IY Uma_Light_V_600_secs_2021-02-15T00-52-52_001.
HISTORY ... fits
HISTORY Bias corrected with ATIK2_BIAS_median_2021-01-18_bin1.fits
HISTORY Dark corrected with ATIK2_DARK_2020-11-27_300_sec_median_bin1.fits
HISTORY and exposure time scaling factor = 2.0
HISTORY Flat corrected with ATIK2_FLAT_2021-02-15_C11_V_mflat_bin1.fits
OK, så here is the fits header of an image that is NOT recognized by VPhot as being plate solved (attached). I can not decode if there is WCS-info in that or not - is there?
I always do alignment, either manually or via Scheduler. I typically slew to a new target, align, take a few images, then slew to another and repeat the process. So there should in principle be WCS information in all images. Right?
I'm a bit confused by how Ekos handles WCS in the sense of when and how the fits header of the images are updated with WCS. I do variable star observations, and up until recently, the software VPhot that I use for measurement (AAVSO online tool) recognized my images from Ekos as having useful WCS info in the fits header. However, recently, that is no longer the case. I have to manually plate solve before measuring.
Now, I am not fully sure which information in the fits header that really is the WCS info, or if anything in this has changed. Or if this is a matter of changes in VPhot. But it would be useful, I think, to have a clear description of what Ekos does in terms of this, and what is saved in the fits header and when. Anyone could help me out with this?
I've tried it with the same results that you have. Profile is not linked to jobs. You can see that in the sequence file - profile comes first, before any job-tag. So it is set once for each sequence file, not for each job file. Apparently (I am not a programmer), this is not easy to change - it has to do with things embedded in the architecture. I've submitted a suggestion to change it in Github, but it demands someone who can work quite a lot with the code for the scheduler.
If you "just" want two cameras to run in parallel, at the same time exposing the same target (like a side-by-side), you can accomplish this with 2 R-Pis, scheduled to start at the same time. One of them will just control a camera, thus loosing framed when telescope is slewing, aligning, dithering etc.
Thanks a lot, that sounds very good. However, I'm thinking of the no-encoder version, CEM120.... maybe not quite as low RMS with that?
Anyway, it sounds as if it was easier and more flexible connecting to Ekos than I first thought. I now feel more comfortable in going forward with these plans.
As a follow up: what do you have on the mounts? I'm planning on having a C11 side-by-side with a 100 mm refractor and a guidescope, setup is around 28 kgs.
I'm considering upgrading my Losmandy G11 mount to an iOptron CEM120, but I want to make sure everything works before actually doing anything. So: how is the status of using this mount with Ekos? I've seen some problem reports here, but does it generally work well? (I'm talking the no encoder version of CEM120)
And how does the mount connect to Ekos? As I understand it, there is no USB port on the mount - or am I wrong?
If I get it right, you'd need to set them up so you can identify them, using the persistent port mapping technique:
However... I have 2 MyfocuserPro version 1, and they are identical in all respects. I can attach them as you say in Ekos, one as Focuser, and one as Aux. But I have no way of knowing which is which nor to make this consistent. All because the Raspberry cannot see any difference between them.
So what I did, was to use 2 raspberries: One focuser attached to each (and of course, Ekos running on both). Doing that, I can give the focuser on Raspberry 2 and alias (for instance Moonlite2) and then connect to it as a remote device from Raspberry 1, and then just do everything from Raspberry 1. I can explain in more detail if you wish.
I haven't had this for a while. But tonight I had a few "solution file doesn't exist". Only when using local astrometry. I could not produce a log - it seemed kstars froze when I switched on log, and it seemed as though it tried to write to /tmp/ but that was not writable? I could not really figure out, clouds came in.
However, I found out that there were index files missing for my FOV - quite small FOV. Could it be that it means that it is an index file that doesn't exist?
I've tried that - using the aux items. And sure, you can connect more than one camera that way. But you only have one capture module - that means, you can only operate one camera at the time.
And the scheduler can not switch between cameras (or profiles, if you use them - profiles are so to speak stored outside of the sequence in the file). If you have a work-around, I'd be most interested. Right now, I use 2 instances of Ekos to accomplish this (each controlling one camera). And for various reasons, on 2 different Raspberries.