[Robin Leadbeater]

Though it does not mean I am right !.  “Solar eclipses” appear to be a special case and should really be called transits or occultations

For me an eclipse involves observing the shadow in the light from a luminous body cast by one body on another body eg as observed from earth between Jupiter and its moons. The observer may be on the body which casts the shadow eg a lunar eclipse. A “solar eclipse” (total or partial) as observed on earth is an occultation or transit and is only an eclipse when observed from a location not on the earth eg from the moon or the ISS when even a “total eclipse” appears partial

Robin

EDIT: I suppose you could call observing the shadow of the moon racing across the landscape  towards you or even noting the darkness of the ground at your feet during a “Total Solar Eclipse” observing an eclipse but for me the sight of the moon in front of the sun is definitely an occultation

[Robin Leadbeater]

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

[Robin Leadbeater]

Ha!  I already use PHD2 and CdC but never realised that function was there 

Thanks!

[Robin Leadbeater]

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

[Robin Leadbeater]

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

[Robin Leadbeater]

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

[Robin Leadbeater]

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

[Robin Leadbeater]

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

[Robin Leadbeater]

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)

[Robin Leadbeater]

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. 

[Robin Leadbeater]

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

[Robin Leadbeater]

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?  

[Robin Leadbeater]

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!

[Robin Leadbeater]

That sounds tough. A back of envelope calculation suggests ~1/32000 change (10 arcsec/30 arcmin)^2

Robin

[Robin Leadbeater]

It was (just) possible with a modified webcam 🙂

http://www.threehillsobservatory.co.uk/astro/TrES_1.htm

[Robin Leadbeater]

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

[Robin Leadbeater]

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

[Robin Leadbeater]

>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. 

[Robin Leadbeater]

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

[Robin Leadbeater]

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.

[Author]

Posts