Skyhound Forums

I think this is strange ask.

I planning another narrow-band mosaic run with the Burke-Gaffney Observatory (BGO) in Halifax. Recently completed one with the Rosette Nebula.

The method I used to position the mount for each panel was offsetting.

The BGO allows centring the mount from a known point--I used a particular star--by providing a horizontal and vertical offset. The offset parameter is a percentage value based on the camera field. For example, if I use OFFSET=-35,0 then I'm saying I want an image 35% of the camera field (long edge) to the west (the negative sign) but at the same declination. After some trial and error, I found the horizontal (RA) offset of 75% gave a decent overlap for the mosaic panels.

I believe that SkyTools can tell me the RA and Dec of the centre of each panel in a mosaic. I suppose I could drive the BGO that way instead.

But I'm wondering if ST4I can calculate offsets for me.

Does it do this? Can I extract offset values for the centres based on a common central star?

Hi Blake,

I can't think of any way SkyTools can help with that directly, but I'll keep thinking on it. Sometimes things that aren't straight forwardly possible can be indeed be done with some ingenuity.

I do wonder though--why use the offset? The tiling in SkyTools figures out the center position for each tile, given the amount of overlap (in pixels) that you specify. Most telescopes can be driven to a specific RA/Dec for each tile. Why wouldn't that work?

I did not find the offset method difficult; it was a simple pattern actually. And I'm inclined to continue to use it.

Yes, I do believe BGO will accept slews with RA and Dec...

How would I extract those coordinates from SkyTools? That I don't know how to do...

I can't recall exactly how your BGO system works, except that you tell it what you want to image and it figures out when to image it, which is a little unfortunate because SkyTools really excels at knowing what filter to image for which object when, and you don't get to take advantage of that. Regardless, my answer turns completely on the word "extract" given that I don't know exactly how you normally extract the information from SkyTools when you set up your imaging on the BGO. Tell me a little about your process and I should be able to give you a procedure.

That said, I've been planning to make a short video once per week, and how to set up a mosaic in SkyTools would make a great topic. If you think that would be helpful, I can make that my first weekly video. Also, if anyone would like to see that, let me know here.

Blake,

Can you send your images to the Astrometry.net website & have them determine the plate scale & center of the field for the images or do you have too many to use that method? If you're using dithering, that probably would require submitting  a lot of images.

Just a suggestion,

Phil S.

hi Greg,

Saint Mary's University offers the BGO to the public, to request images using social media. Students and researches get high priority and then the rest of us get queued up after them. You're right, we never know when the data will be captured. That said, there are maximum moonlight, minimum elevation, side of pier filters that can be adjusted to narrow down, a smidge, when things might happen. I've done a lot of imaging (over 630 requests) and timed a bunch of them in the "off season" i.e. the summer time when there were not a lot of students around.

An image request is submitted by some means, I regularly use a custom app, and sometimes email. The system supports Twitter and Facebook Messenger.

The target is typical specified by a supported catalogue ID or common name. For the Rosette, I chose a star near the middle, HIP 31130. SkyTools helped with that.

Initially I was using SkyTools 3 Pro with the 'scope and camera profiles configured. I knew the exact framing within the nebula. I determined that I would need a 4 x 5 arrangement with slight overlap to capture the main extent.

As mentioned, I used some trial and error test shots to determine the appropriate offsetting values to use. From the documentation: "This parameter offsets the telescope's position from its catalog position by the specified amounts in right ascension (offsetra) and declination (offsetdec). The values are specified as the percentage of the field of view (see the fullsize parameter above) and can range from -500 to 500 percent. Positive values of offsetdec move the position north and positive values of offsetra move the position east." It took me a little while to get that sorted.

I used:
horizontal offset +/- 75
vertical offset +/- 50

I submitted jobs using the following command:
#request
offset=?,?
object=HIP31130
minalt=48
"comment=Rosette Mosaic"
fullsize=yes
special=LUM2,60,10,HA,60,10,OIII,60,10
maxmoon=10

with the appropriate offset values... The LUM2, HA, and OIII indicates the required filter, which indirectly specifies the SBIG camera. The 10 subs for each filter are 60 seconds (that's the max).

I actually made a PowerPoint file with a screen grab from SkyTools, rectangles sized for the camera frame, and I used it to plan and track progress. See the blog post to get a sense of how I did that:
http://blog.lumpydarkness.com/2022/08/re...tures.html

The morning after an imaging run, the BGO does pre-processing. The light subframes are registered and stacked with flats and darks applied. A user receives a single FITS for each requested filter. I typically run with that. I stretch and convert with FITS Liberator and then assemble typically in Photoshop.

Here's a blog post from a recent acquisition.
http://blog.lumpydarkness.com/2022/10/co...-tile.html

Does that make sense?

Looking at the list of commands here: https://observatory.smu.ca/bgo-useme/bgo-commands

It appears to me that the only way to target a specific RA/Dec would be to use the #addobject command first, giving it a name that you would reference later for the tile position. Is there another way to do it? If not, do you have permission to use this feature, and are these new objects added to a database shared by everyone, or just your own user-related database?

Here is the bigger question: given that I already wrote very similar code to do the calculations for ACP Expert, which also uses calculated constraints, and that the format of the commands is so simple, it would be very easy to create output directly for use with this control system. My guess is that they are using ACP Expert behind the scenes, and have created a very simple text-based interface to it. I suppose it is possuble that this is also a feature of ACP Expert that I am unfamiliar with? Or perhaps this control system is something they cooked up entirely themselves?

Here's the point: if this control system exists in the same form elsewhere, and its not just this one telescope, then I should add support for it directly from SkyTools. Any info about that?

I believe the control system is home-grown. Dave Lane built it (along with the planetarium software The Earth Centred Universe). I too have wondered about this... I even considered writing my own GUI front-end to generate requests. As you have observed, it is a very basic command set. And it is matured, i.e. been in use for a while.

It is also used with his home set-up, the Abbey RIdge Observatory (ARO) which I have access to. And the Mini-Ralph Observatory (MRO) with a wide-field refractor in it's own little weather-resistant structure.

I could talk to Dave about this... He's official retired from the university now, as an aside.

Or we could all meet up!

I thought there was a way to specify RA-Dec coords directly and not be necessarily adding something... but I could be wrong.

It would ROCK if SkyTools could generate my complete mosaic command set requests.

It would also be really easy, like a couple of hours of work. Not like adding support for NINA (which is coming along nicely right now BTW).

But I'd need to know if you have access to the ability to use the #addobject command, and whether or not adding a bunch of extra objects to the database would cause problems for the system or for other users.

I'd love to meet up! I'll be over in a few minutes. Seriously tho, we could meet on zoom or something, although I'm not sure that's really necessary.

Woo hoo. I pinged Dave and explained the situation.

He confirmed the comment language currently does not allow RA-Dec coords. But he shared in the back-end, it is looking up and storing these data in the database. And then he said, why not? So he's going to do some dev work to support it!

That was easy!