Forum Replies Created
-
Posts
-
I use the predefined mode with my ALPY but I use the file mode quite a bit with my LHIRES for cases where there is not a preconfigured setup. As well as the list of lines, the file contains the order of the fit you want and the approximate linear dispersion needed to approximately locate the lines so it is specific to a particular spectrograph and camera combination. You can generate your own file by doing a manual linear calibration first using the set (or subset) of the lines and noting the linear coefficient. (or you could try the linear coefficent from the fit generated using the predefined mode)This is then added to the list of line wavelengths along with the order of fit you want. (Note that it can fail if the dispersion is sufficiently non linear and the lines so closely spaced that the wrong line is picked. To avoid this, I suspect the predefined mode for the ALPY may allow for the non linearity of the instrument which the file mode does not allowing some more close spaced lines at the blue end to be used.) A typical file for the LHIRES looks like this for example
2
0.2461
6532.882
6598.953
6717.043
6752.834
where 2 is the order of the fit and 0.2461 is the linear dispersion (A/pixel)
(Ignore the doublespacing generated by the forum software)
Cheers
Robin
A related question – Are there any guider programs which will track moving objects relative to an offset guide star, allowing long exposures ? (I was issued with a challenge to take a spectrum of Borisov which I declined but it might be interesting to know how it might be done for future reference)
Robin
Hi Kevin,
There are a couple of people on the AAVSO forum looking at SS Cyg using Star Analysers with some success. I have been pointing them to yours (and others), spectra in the BAA database 🙂
Cheers
Robin
It does look a bit like that but no, it is just the result of normalising each row of a spectrum which is slightly tilted. Here is the whole “corrected” flat. The vertical gain correction algorithm only works correctly if the dispersion is exactly along the row direction.
This is a severe obvious case but some variations along the slit are much more subtle. For example these in a highly stretched LHIRES flat image from last night are down at the 1% level and are in the region where I take spectra. They are not anything to be too concerned about as an uncorrected flat should work ok to divide them out but not if they are tilted and I apply the vertical gain correction
Hi Andrew, David
I have some reservations. The artifact from the dust line is worrying (There is a technical name for these isn’t there?). They wont be a problem in the sky background subtraction as they will average out but if they occur where the spectrum is binned they could distort the spectrum or at least give the wrong total flux. In fact a conventional flat would work correctly in this region, correcting the flux for the loss of light but the gain corrected flat would give the wrong flux even if the dispersion was exactly horizontal
Cheers
Robin
Here is the comparison with and without vertical gain correction.(The step on the right hand edge is outside the corrected area)
It flattens the profile as expected but note the artifact where the dust on the slit was, caused by the dispersion direction not being exactly aligned with the rows (tilt). This is an extreme example of course but there must always be some small errors across the whole flat if there is any tilt. (Note when measuring these column profiles accurately any slant/smile should be removed otherwise this can distort the profile measured in a vertical slice)
The profiles were produced using a rather obscure French program called Teleauto which I found when I started doing some photometry. (I forget the name of the author now)
http://www.teleauto.org/indexEn.php
It is obsolete now (only handles 16 bit images and struggles to run properly on win7) but it has some cool unusual features, particularly for its day (~15 years ago)
Cheers
Robin
OK, for my setup the profile along the slit for sky flats is flat within ~+-2% but the internal lamp flat drops off by ~20% over the bottom third, presumably due to uneven lamp illumination, so unless this can be adjusted out somehow, it looks like the internal lamp flat would better match the true situation if the vertical gain tool is used. (The narrow dip on the left (bottom) edge is dirt on the slit)
Hi Andrew,
I think the algorithm just rescales each row the to the same mean level (on the assumption that the variation in mean from row to row is due to uneven illumination from the lamp or possibly variation in slit width) rather than averaging the columns so the pixel-pixel variation should still be there.
Hi Andrew,
I think for me the main problem the flat solves is getting rid of the ripples in the ATK428 camera response when used with the ALPY, that are otherwise difficult to accurately remove using an instrument response generated using a reference star, because of their rather close spacing
Yep plenty of signal to knock down the stochastic errors and a large area to average out the seeing. The question is how stable is the camera electronics (gain and dark current) and the atmospheric transparency at the sort of timescale we a talking about?
Hi Grant,
Mostly beginners luck really. Back then I was just scratching around for interesting science based projects to do with my modified webcam and knew very little about measuring variable stars, otherwise I probably would not have even tried!
That sounds tough. A back of envelope calculation suggests ~1/32000 change (10 arcsec/30 arcmin)^2
Robin
It was (just) possible with a modified webcam 🙂
If it is just a simple demonstration of a dip you are after, perhaps you could use the guiding program PHD which can produce a graph of the “mass” of the selected star in the field in real time. (using a zwo camera with its all sky wide field lens?)Not sure if you can scale the graph to show a small dip though
Cheers
Robin
These types of star have have distinctly sawtooth pulsations with the rise time shorter than the fall. eg YZ Boo has a catalogued rise time of 31% which seems to tally with the actual light curve
EDIT:from the catalogue field descriptions
Rise_Eclipse_Time
This parameter contains either the rise time (M-m) for intrinsic variables, or the duration of the eclipse (D) for eclipsing binaries, both given as a percentage of the period value for the star. These values help to define the shape of the light curve.Cheers
Robin
>It would rely on a bit of luck with the timing – if the capture started at the maxima or minima there would be no difference in the pulsar’s brightness between the frames. Also I’m not sure you could trust the camera to run at a constant speed and not drop frames whilst capturing.
I think provided the exposure time is short enough (less than the max to min), the frame rate just needs to be known and stable (and just different from, even slower, than the pulsar). You can then assign a relative phase to each frame and stack the frames in groups with similar phase. A quick initial test would be to test if the pulsar can be seen in a simple stack of short enough exposures. If so then seeing the pulses should just be a matter of picking the right ones out and stacking them. In theory I suspect you could even find the pulsations without knowing the period.
I know it is possible directly with a 1m scope and an EMCCD based camera which has effectively zero read noise
https://www.cloudynights.com/topic/285383-crab-nebulass-pulsar-is-blinking-not-a-joke/?p=3632352
but it might be interesting to run the figures for a modern CMOS camera to see if given a reasonable size scope, summing enough images at each phase could pull the signal out
Robin
Well H alpha is there with the right sort of width for a nova (FWHM ~2500km/s) and probably H beta with similar width but the bright sky background has dragged the SNR down to single digits so nothing else is showing above the noise.
