Shelyak eShel

[William Ketzeback]

Hello Bob,

I wanted to let you know my upgrade to new 64bit versions of ACP, MaxIm, FocusMax, DomeMax II under windows 10 went well. The separation of the DFM TCS and Focuser to a different computer with ASCOM Remote also went very well. We are still tracking down a few things I may have missed along the way but it was going well up until we closed the observatory yesterday as a non-essential business per the Governor of NM for the COVID-19 pandemic.

I did a search on previous postings (and am reaching out) to see if anyone had successfully integrated a Shelyak eShel spectrograph into ACP. I realize all the challenges are in the details! Have you or anyone you known taken on the challenge? Its my current project from one of our partners. Please let me know who I might reach out to that has tried.

Best wishes to everyones health!
Bill

[Bob Denny]

There have been a couple of attempts but none recently. The main challenge appears to be identifying the desired target in the acquisition camera (which is too small to plate solve). Also flexure is an issue if there is a port selector involved. Once you look closer, feel free to call and chat.

[Peter Prendergast]

Its simply impractical....I worked with that system for a few years. Bob is quite correct....as you know the FOV typically holds no more than 1 or two stars so you
really need to know what your doing and have superb aiming. I was fortunate and used a Planewave Ascension mount, which I still have, and always got my star.

The best you can do is use TSX to aim the scope, then use TSX to center the star. As you are surely aware, you can move that pick off fiber in the FOV where ever you like.
I always put it in the dead center. Then TSX can dump the star with ONE click right on it. Worked like a charm and saved oodles of time.

I had it down to a science and on a good night could pop off ten objects! Of course I was using a 24 inch scope, still have that too, small ones make it tougher.
Tried with a 20 inch could barely do mag 7 and at that took to darn long. Cosmic hits would wreck the orders.

Used a 30 inch scope WOW was that a delight, but that one was at the local college.

Well enjoy, getting the data is cake, its reducing it that's a bugger. Oh, one other thing, I kept my eschell inside a freezer I bought at Sears, kept it at 20 deg F.
Then in the winter the freezer hardly worked at all, and in the summer it worked a bit harder BUT the temp was always PERFECT, and as a result those orders
and lines didn't move a BIT was much much easier to reduce the data because of the superb temperature stability.

If you go the route of the freezer, be aware NOT to open it up after the eschell had cooled or you'll get condesate on the mirror. To avoid
this, just open it enough to get your arm in the focus. I did this and had no trouble after I learned the hard way NOT to open it and pull it out!

HTH
Peter

[Bob Denny]

Thanks Peter, I appreciate the support and more than that, the good info for Bill!!

[William Ketzeback]

Great tips! I'll see if I have room in my dome for a freezer. I have a spare one but not much room in our dome. We are integrating our eShel on a 24 inch Classical Cassegrain. My client wants to do super bright star work. Nothing as faint as 7th magnitude. For fainter stuff we have an Echelle on our 3.5-m that can go from 5th down to about 13th. We do have lots of experience reducing this sort of data here at the observatory. Right now I am more concerned about pointing accurately enough. It is an interesting idea to slew to field and offset using an off axis guider then switch to the guider on the fiber injection module for guiding. I'll have to consider that. Thanks again for the advice.

[Peter Prendergast]

When you use the freezer, be sure to keep it CLOSED or the prism will fog over. While focusing, I used to lift the lid just enough to get my arm in to turn the focus ring. Once focus is
set you'll never have to open the freezer again. NEVER take it out unless you mean to leave it out for many hours or it will instantly fog/freeze over.
Absent that, it works GREAT the orders never move and processing goes way faster.
Enjoy!
Peter

[Bob Denny]

This is really great Peter thanks!!!

[Eric Jensen]

Thanks to all for sharing their experiences here. I have been pondering this a bit as well for our eShel, and I wanted to float a relatively simple (I think) idea out here and see what people think. It's not a complete solution, and certainly not intended as a general-purpose spectroscopy solution for everyone, but I wonder if it could go a ways toward helping with this setup. It's essentially a question about how MaximDL guiding handles some of its scripting parameters, and perhaps to some extent how ACP interacts with Maxim's guiding as well.

My assumptions:

• You have a telescope with a good enough pointing model that you are able to put the desired star into the field of view of the guider (which for the eShel is viewing the fiber end and the reflective surface around it).
• The desired star is always the brightest star in that small field of view. (This seems pretty likely since you need a lot of photons to get a decent spectrum, though it might not work for some close binaries.)
• The X,Y coordinates of the fiber end are always at the same position in the guider image.

If the above conditions are satisfied, it seems like it ought to be possible to acquire the target as follows:

1. Tell ACP to point at the desired coordinates.
2. Do not attempt to plate solve and re-center. (I think "disable auto-center" is the way to turn this off in ACP?)
3. Start autoguiding - this should find the brightest star (which by assumption is the desired target star) and start guiding on it, wherever it is in the FOV.
4. Call a custom script that runs MaximDL's GuiderMoveStar method, to change the desired X,Y coordinates of the guide star to the known coordinates of the fiber end, and continue guiding there. If I understand it correctly, this tells MaximDL, "I want the guide star to be centered at these X,Y coordinates."
5. Might be also necessary to increase the guiding exposure time at this point if a lot of light goes down the fiber - whether this is necessary probably depends on how the seeing compares to the fiber diameter.

Does this seem reasonable? I'm happy to hear any thoughts. I don't have a lot of experience with MaximDL scripting, but it seems like that routine could yield the desired effect of getting the star on the fiber, at least in this scenario.

A couple of questions for anyone more knowledgeable about MaximDL and ACP:

1. I'm assuming that the X, Y coords needed are relative to the full guide camera field of view rather than the guider track box image. Otherwise this won't work since the track box could be anywhere relative to the full guider FOV.
2. Is there an ACP hook/scripting point available at about the right point in the imaging sequence? It would be after target acquisition, and ideally after guiding starts, but before starting to image. If it's not possible to have this play nicely with ACP's own interactions with the guider, it could be possible to have the custom script handle all of the guiding itself - it would be more commands, but essentially just adding the initial exposure and starting the tracking before moving the star. Looking at the ACP docs, it seems like TargetStart is too early (no slew yet) and ImageStart is (maybe?) too late - though maybe the latter would be OK if it's possible to tweak guider parameters there. It seems like there would be no harm in calling GuiderMoveStar before every image, even if the X,Y didn't change (though a cleaner way would be just to check first and call only if necessary). Might need some guider settling logic in there as well.

Thanks,

Eric

[Peter Prendergast]

Thanks to all for sharing their experiences here. I have been pondering this a bit as well for our eShel, and I wanted to float a relatively simple (I think) idea out here and see what people think. It's not a complete solution, and certainly not intended as a general-purpose spectroscopy solution for everyone, but I wonder if it could go a ways toward helping with this setup. It's essentially a question about how MaximDL guiding handles some of its scripting parameters, and perhaps to some extent how ACP interacts with Maxim's guiding as well.

My assumptions:

• You have a telescope with a good enough pointing model that you are able to put the desired star into the field of view of the guider (which for the eShel is viewing the fiber end and the reflective surface around it).
• The desired star is always the brightest star in that small field of view. (This seems pretty likely since you need a lot of photons to get a decent spectrum, though it might not work for some close binaries.)
• The X,Y coordinates of the fiber end are always at the same position in the guider image.

If the above conditions are satisfied, it seems like it ought to be possible to acquire the target as follows:

1. Tell ACP to point at the desired coordinates.
2. Do not attempt to plate solve and re-center. (I think "disable auto-center" is the way to turn this off in ACP?)
3. Start autoguiding - this should find the brightest star (which by assumption is the desired target star) and start guiding on it, wherever it is in the FOV.
4. Call a custom script that runs MaximDL's GuiderMoveStar method, to change the desired X,Y coordinates of the guide star to the known coordinates of the fiber end, and continue guiding there. If I understand it correctly, this tells MaximDL, "I want the guide star to be centered at these X,Y coordinates."
5. Might be also necessary to increase the guiding exposure time at this point if a lot of light goes down the fiber - whether this is necessary probably depends on how the seeing compares to the fiber diameter.

Does this seem reasonable? I'm happy to hear any thoughts. I don't have a lot of experience with MaximDL scripting, but it seems like that routine could yield the desired effect of getting the star on the fiber, at least in this scenario.

A couple of questions for anyone more knowledgeable about MaximDL and ACP:

1. I'm assuming that the X, Y coords needed are relative to the full guide camera field of view rather than the guider track box image. Otherwise this won't work since the track box could be anywhere relative to the full guider FOV.
2. Is there an ACP hook/scripting point available at about the right point in the imaging sequence? It would be after target acquisition, and ideally after guiding starts, but before starting to image. If it's not possible to have this play nicely with ACP's own interactions with the guider, it could be possible to have the custom script handle all of the guiding itself - it would be more commands, but essentially just adding the initial exposure and starting the tracking before moving the star. Looking at the ACP docs, it seems like TargetStart is too early (no slew yet) and ImageStart is (maybe?) too late - though maybe the latter would be OK if it's possible to tweak guider parameters there. It seems like there would be no harm in calling GuiderMoveStar before every image, even if the X,Y didn't change (though a cleaner way would be just to check first and call only if necessary). Might need some guider settling logic in there as well.

Thanks,

Eric

unfortunately this will not work. The star of interest is by no means always the brightest star.
that alone is a stopper. You may end up providing specious data.

while not perfect I’ve used TSX with excellent results. Put the fiber in the center
TSX will put the star you wish right on it.
not automatically done but highly reliable

[Eric Jensen]

unfortunately this will not work. The star of interest is by no means always the brightest star.
that alone is a stopper. You may end up providing specious data.

Thanks for the quick reply. While what you say may be true for your use, it's quite likely that the "brightest star" assumption will be true for my use of this - with a 24" scope and poor seeing (resulting in somewhat less light down the fiber) I'm unlikely to tackle very faint stars. With f/7.8 we also have a relatively small field of view for the guide camera. And it's easy enough to check beforehand to see if a given target has bright neighbors.

So I'm still interested to hear thoughts about the feasibility of this given the assumptions. Of course you're right that if the assumptions don't hold, it won't work.