Star names

originally posted by: ngchunter

originally posted by: tanka418
By the way; have you seen what I'm trying to do? And, what might your thoughts be?

If you're serious about using a nexstar telescope you're going to need a good autoguiding solution. A nightscape camera uses quite small pixels for an 8" Schmidt-Cassegrain, so I would advise using Fastar. Didn't see that mentioned but maybe you were already planning to do that. External guiding can produce flexure, which is why I much prefer to use a CCD camera with internal guiding. If you do use an external guide scope, be sure to put a guidescope ring around the focus tube and support it to minimize differential flexure of the scope.

Guiding....yes been down that road. The problem isn't so much in the provisioning of such a thing, it more in the automation. Most guide systems rely heavily on the Human operator, and that presets an issue with the "remoting", although I have found components that can provide at least some of the functionality required.

My thought so far are using an off-axis guide system, though I am concerned with using such a thing as it appears to interfere with using additional lenses (presuming I can automate lens change). This lens change automation may become a ore serious issue over time.

I've not seen any cameras that contain any guiding features, though, with the computer vision libraries I have, I suppose I can make the camera handling more intelligent and let the computer do all of that. If you have any suggestions on cameras, please...

I want the smaller pixels, and resulting higher pixel count to help make image post processing easier...I can get better "zoom"/enlargements with more pixels. I can also detect smaller changes, smaller "signal", and achieve better data collection with higher resolution.

originally posted by: tanka418

originally posted by: ngchunter
I once created a lunar calculations spreadsheet by scanning very similar tables out of a book, just image data, and then used microsoft software built into windows to perform machine reading of the data to translate it into ASCII text I could import into Excel. It wasn't really that hard.

Hmmmm...I wasn't aware that there was ever OCR methods in Windows, and I've been developing for Windows for several decades...Be that as it may; I don't currently have any OCR installed, and I'm not too keen on writing any (I have computer vision libraries)...

Well I can only lead a horse to water. I guess you never used Microsoft Office Document Imaging. If you have Office 2007 or older you already have it installed. Otherwise you can install it here:
support.microsoft.com...

Distance isn't an important variable to cross reference the data, just the RA and the Dec. Why should that be "avoided?"

Actually...distance is required; for instance...IF I were to attempt this with the star Sirius, the probability increases to an unacceptable level due to the fact that there are three (3) stars in proximity; Sirius A, Sirius B,

Those are components of the same system, hence the multiple stars list in Hipparcos.

Nu2 C.M. all three of these stars have a RA, and Decl that is very close.

Nu2 does not share the coordinates of Sirius. If your ability to calculate for precession is so inaccurate that you could confuse the coordinates of Nu2 Canis Majoris, which are RA: 06h 36m 41s Dec: −19° 15′ 21″ with Sirius which is RA: 06h 45m 08.92s Dec: −16° 42′ 58.02 in J2000, then you really need to work on your math. You should be able to easily distinguish those stars based on their RA and Dec alone.

The published values of RA and Decl may not necessarily agree with the computed values,

Then I suggest you work on your ability to compute the values properly.

and while the difference will be too small t make a difference to a Human,

The above difference makes a huge difference to an astronomer like me.

it will make a difference to a computer...if I calculate to 7 or 8 decimal places, all must agree or there is no match...

You should be able to cross-reference these catalogs to within easily enough accuracy to distinguish stars like Nu2 and Sirius based on RA and Dec alone. You will need to calculate for proper motion and precession, of course, but the proper motion values, where it is important, is already contained in the Hipparcos data. Precessing the coordinates of the list from NASA that I gave you will yield coordinates accurate enough for a match to within an arcsecond or so. For example, taking the Epoch 1950 coordinates of Sirius from the NASA list I gave you and calculating for precession and proper motion I get the following coordinates: RA: 6 45 8.43 Dec: -16 -42 -58.95. That's close enough for a match even with a stringency of a small fraction of an arcminute, and given that there are only some 537 names distributed throughout the entire sky there is really no risk of confusion there. If you want to add a third factor then you could take apparent magnitude into consideration; all stars with common names are going to be naked eye magnitude. That wouldn't exclude Nu2 Canis Majoris of course, but the coordinates would.

And since I will be asking SQL Server to use numerical data as a "key" all digits must match very precisely.

Then round up to the nearest arcminute, or if you want some extra stringency, the nearest tenth of an arcminute. If you do the math properly you'll get an exact match even at that level with no confusion among the named stars.

Yes I am serious about this project. I've been a software engineer for over 40 years, so the precision, math, and other aspects of this project are nothing new...I only need to map out what I need to be doing...and I don't expect it to be easy...I expect and demand serious challenge. I also expect a great deal of what I think of as "FUN".

Then the above calculations should be very easy for you. I did them myself just now in just a couple minutes.

originally posted by: tanka418

originally posted by: ngchunter

originally posted by: tanka418
By the way; have you seen what I'm trying to do? And, what might your thoughts be?

If you're serious about using a nexstar telescope you're going to need a good autoguiding solution. A nightscape camera uses quite small pixels for an 8" Schmidt-Cassegrain, so I would advise using Fastar. Didn't see that mentioned but maybe you were already planning to do that. External guiding can produce flexure, which is why I much prefer to use a CCD camera with internal guiding. If you do use an external guide scope, be sure to put a guidescope ring around the focus tube and support it to minimize differential flexure of the scope.

Guiding....yes been down that road. The problem isn't so much in the provisioning of such a thing, it more in the automation. Most guide systems rely heavily on the Human operator, and that presets an issue with the "remoting", although I have found components that can provide at least some of the functionality required.

At iTelescope.net we have automated the selection of guide stars.

I've not seen any cameras that contain any guiding features,

Mine does. Lots of them do.
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...

I want the smaller pixels, and resulting higher pixel count to help make image post processing easier...

Well, it's your funeral. Smaller pixels at the full f/10 focal ratio and 2 meter focal length is a recipe for disaster with that mount. Errors in tracking will ruin the quality of your images at that image scale and autoguiding will likely not save you even at fairly rapid guiding cadences (1-2 seconds). Yes, much of the reported 30 arcseconds peak to peak of periodic error can be trained with periodic error correction, but you're going to learn that the PEC correction cadence dictated by the encoder resolution isn't enough to save you from rapid errors of the gear motion. Getting the autoguider to precisely correct in a single rapid pulse is also likely a lost cause at that resolution. I would advise larger pixels, you don't need 10 megapixels of resolution to get beautiful images in post processing. Sampling the angular resolution at no finer than about 1.5 arcseconds per pixel at most is advised with that mount. And even that may be pushing it.

originally posted by: ngchunter

Mine does. Lots of them do.
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...

Nice technology, a bit pricey though...for instance, that 8.3MP device from Kodak is about half the cost elsewhere, though without some of the features.

Well, it's your funeral. Smaller pixels at the full f/10 focal ratio and 2 meter focal length is a recipe for disaster with that mount. Errors in tracking will ruin the quality of your images at that image scale and autoguiding will likely not save you even at fairly rapid guiding cadences (1-2 seconds). Yes, much of the reported 30 arcseconds peak to peak of periodic error can be trained with periodic error correction, but you're going to learn that the PEC correction cadence dictated by the encoder resolution isn't enough to save you from rapid errors of the gear motion. Getting the autoguider to precisely correct in a single rapid pulse is also likely a lost cause at that resolution. I would advise larger pixels, you don't need 10 megapixels of resolution to get beautiful images in post processing. Sampling the angular resolution at no finer than about 1.5 arcseconds per pixel at most is advised with that mount. And even that may be pushing it.

Interesting...where did you get the data...error rates, percentages, etc. I couldn't find those specs at the Celestron site. I can understand shortcomings in the robotic arm, but, seriously, robots had greater precision back in the mid 80's, One would thing that it improved over time, but I guess there is no guarantee...

originally posted by: tanka418

originally posted by: ngchunter

Mine does. Lots of them do.
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...

Nice technology, a bit pricey though...for instance, that 8.3MP device from Kodak is about half the cost elsewhere, though without some of the features.

The features are worth every penny. I use an SBIG ST-2000XCM. It's 2 MP but it produces some gorgeous images and the self guiding makes it far more valuable to astrophotography than my much cheaper but higher resolution Canon T5i. The true value of an astronomical CCD is not just the resolution, and the pixel size needs to be carefully chosen to pair well with the telescope.

Interesting...where did you get the data...error rates, percentages, etc.

15 years of experience in astrophotography, most of that spent operating an 8" Schmidt-Cassegrain. I found the exact number for the periodic error of your scope in this article:

I measured the peak-to-peak periodic error of the telescope’s polar/azimuth axis to be just under 30 arcseconds.

astronomynow.com...

I couldn't find those specs at the Celestron site. I can understand shortcomings in the robotic arm, but, seriously, robots had greater precision back in the mid 80's, One would thing that it improved over time, but I guess there is no guarantee...

Nexstar is not a high end mount. If you want a near complete absence of periodic error (corrected by high resoluti to the extent that guiding is not necessary you'll need to pay a lot more and buy one of these:
planewave.com...-GKL4E

originally posted by: ngchunter

Well I can only lead a horse to water. I guess you never used Microsoft Office Document Imaging. If you have Office 2007 or older you already have it installed. Otherwise you can install it here:
support.microsoft.com...

Yeah...well as a Microsoft developer it is kid of in my best interest to have the latest and greatest installed...does't mean I like it, and there are several things about the latest and greatest I don't like much...

Nu2 does not share the coordinates of Sirius. If your ability to calculate for precession is so inaccurate that you could confuse the coordinates of Nu2 Canis Majoris, which are RA: 06h 36m 41s Dec: −19° 15′ 21″ with Sirius which is RA: 06h 45m 08.92s Dec: −16° 42′ 58.02 in J2000, then you really need to work on your math. You should be able to easily distinguish those stars based on their RA and Dec alone.

...

Then I suggest you work on your ability to compute the values properly.

Clearly you do not understand the nature of this issue. In these published tables, there are values that ultimately work out to a decimal number with 6 or more digits of precision. These numbers MUST be the same in all instances or the SQL engine will not find a match. The difference of some microarcseconds is quite critical to the SQL engine, but not so much to a Human...if you had a misalignment of 1 or 2 microarcseconds; you wouldn't notice, especially a near distances (2 digit parsec)...the difference is too small to be of consequence. However; that difference to the SQL engine means failure to identify, and thus no data selection where one should occur.

The issue isn't one of computing ability either, there is a set equations for doing these things, I even have it in my library, but there can be errors in the very fine grain due to math coprocessors, how old they are, data types employed and the math classes being used. again, these are differences that are so small that a human, or indeed a telescope, wouldn't take much notice, but, SQL Server will.

Further, because of these small differences, I have to include a range of "error" that will compensate for these computational differences and still yield the correct result. Most of this is a SQL engine issue...

originally posted by: tanka418

originally posted by: ngchunter

Well I can only lead a horse to water. I guess you never used Microsoft Office Document Imaging. If you have Office 2007 or older you already have it installed. Otherwise you can install it here:
support.microsoft.com...

Yeah...well as a Microsoft developer it is kid of in my best interest to have the latest and greatest installed...does't mean I like it, and there are several things about the latest and greatest I don't like much...

MODI worked just fine for me when I used it to turn my book of lunar tables into useful data for calculating in the computer. If you want to make excuses for not installing MODI, I can't help you, it's what I still use and it still works for me.

Nu2 does not share the coordinates of Sirius. If your ability to calculate for precession is so inaccurate that you could confuse the coordinates of Nu2 Canis Majoris, which are RA: 06h 36m 41s Dec: −19° 15′ 21″ with Sirius which is RA: 06h 45m 08.92s Dec: −16° 42′ 58.02 in J2000, then you really need to work on your math. You should be able to easily distinguish those stars based on their RA and Dec alone.

...

Then I suggest you work on your ability to compute the values properly.

Clearly you do not understand the nature of this issue. In these published tables, there are values that ultimately work out to a decimal number with 6 or more digits of precision. These numbers MUST be the same in all instances or the SQL engine will not find a match.

What part of "round to the nearest tenth of an arcminute" did you not understand? You should be able to do that through a simple batch function of some sort and it will provide more than enough accuracy AND match exactly to a tenth of an arcminute if you do the calculations properly.

The difference of some microarcseconds is quite critical to the SQL engine,

Then round them off first for matching the ID's!

The issue isn't one of computing ability either, there is a set equations for doing these things, I even have it in my library, but there can be errors in the very fine grain due to math coprocessors, how old they are, data types employed and the math classes being used.

You're handwaving. If you calculate for precession and proper motion properly you would have no trouble precessing the B1950.0 coordinates to the epoch used by Hipparcos and cross reference the coordinates to within a tenth of an arcsecond.

a reply to: ngchunter

For the most part the cross-referencing of star data isn't an issue. There are some small issues that have to be dealt with, but, I have great experience in manipulating databases and I'm very confidant I can work out a foreign key that will operate across several tables (HIPP, XHIP, 2MASS, Kepler, etc.) . Even if I don't quite like the data types being used.

I'm more concerned about the tracking issues, but, I "think" I have a handle on that, and also feel that I can compensate for at least some of that in software.

Currently I'm kind of thinking that I can implement a tracking system that may be more accurate than what you are used to, and do it with the main camera and the addition of a little AI. I'm also thinking that I can "map" the periodic errors and compensate to some degree...I guess I'll have to try it to find out...but, hey, that's the nature of engineering.

Thank yo so much, man...this has been wonderful and very educational.

Hi Tanka,

I think we had this conversation before and I think I know what you're after. You should know that only around 1000-1500 stars actually have "proper names" by that I mean historical names like (Capella, Sirius, Procyon, Betelgeuse, Alcor, Mizar, Aldebaran, etc) These are typically the brightest stars in the sky.

This is because the human eye typically can only see down to a 7th magnitude.

After telescopes were invented and we found massive amounts of fainter stars it became impractical and unnecessary to assign a proper name to every one so instead they were assigned numbers in whatever catalog the astronomer created ie: Henry-Draper, Gliese, Lalande, Durchmusterung, etc.

This practice continues today with things like the 2MASS (2 Micron All Sky Survey), Hipparcos and Kepler catalogs. As you well know the same star can appear in multiple catalogs.

For very dim stars you will not have a proper name.

If you haven't come across Flamsteed Designation stars (stars like 47 Ursa Majoris or 82 Eridani for example) then check out this table. While they're not the same as proper names they are slightly more interesting names from a layperson standpoint than "HIPXXXXX".

In the end though you will have a combination of different catalog name/number stars which don't have names as well as proper names and Flamsteed designations.

originally posted by: tanka418
a reply to: ngchunter
I'm more concerned about the tracking issues, but, I "think" I have a handle on that, and also feel that I can compensate for at least some of that in software.

Currently I'm kind of thinking that I can implement a tracking system that may be more accurate than what you are used to, and do it with the main camera and the addition of a little AI. I'm also thinking that I can "map" the periodic errors and compensate to some degree...I guess I'll have to try it to find out...but, hey, that's the nature of engineering.

You can map the periodic error, that's what Periodic Error Correction does. It's already in the firmware of the telescope. The problem is that the resolution of the optical encoders of that telescope are too coarse and so when you playback the correction it has to determine where the playback should begin and what pulses should be given based on the pulses received from the optical encoder. If you intend to improve on that you would need to improve the resolution the optical encoders. If you intend to write your own periodic error correction software, you'll also need to be tied directly into the telescope's optical encoders. Either way you're not going to be able to do that without re-engineering the telescope itself in some way. Not saying you can't or shouldn't do that, but I am used to very accurate tracking systems. See the above Planewave mount. We use several of those at iTelescope.

a reply to: JadeStar

Hey Jade,

Yes we have touched on this before....I was sort of hoping to find more than I had, though I didn't expect "proper names" for all.

I have run across the Flamsteed designation, but haven't looked into it very far...guess I will now...

What I currently have is a "join" on Hipp and a view containing the appropriate "proper name". This is allowing me to search for an object with either the name or its number. So what I need t do now is combine Flamsteed data with this query system.

This wee search engine is part of a TelescopeUI I'm working on...enter or select an object, the system will seek it, etc.

Firstly, thank you for all the help...

I found that the HabHYG table has all of what I was looking for. It contains some 3000+ BayerFlamsteed identifiers, along with HIP translations. So, I've been rewriting some of my SQL "views" t use the improved dataset. This also allows me to deploy over 117,00 stars without having to alter the datasets (add corrected RA / DECL).

@NGCHUNTER While I a still planning on the higher resolution camera, your concerns have not fallen on deaf ears. It's just that I have to rewrite many of the drivers used, and think I can improve on things...we'll see...in any case, I don't have a problem with "rolling back" the camera resolution.

In the meantime y'all, I'll continue to develop my database, and other aspects of the system.

originally posted by: ngchunter

originally posted by: tanka418

originally posted by: ngchunter

Mine does. Lots of them do.
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...
Self-guiding:
www.sbig.com...

Nice technology, a bit pricey though...for instance, that 8.3MP device from Kodak is about half the cost elsewhere, though without some of the features.

The features are worth every penny. I use an SBIG ST-2000XCM. It's 2 MP but it produces some gorgeous images and the self guiding makes it far more valuable to astrophotography than my much cheaper but higher resolution Canon T5i. The true value of an astronomical CCD is not just the resolution, and the pixel size needs to be carefully chosen to pair well with the telescope.

Interesting...where did you get the data...error rates, percentages, etc.

15 years of experience in astrophotography, most of that spent operating an 8" Schmidt-Cassegrain. I found the exact number for the periodic error of your scope in this article:

I measured the peak-to-peak periodic error of the telescope’s polar/azimuth axis to be just under 30 arcseconds.

astronomynow.com...

I couldn't find those specs at the Celestron site. I can understand shortcomings in the robotic arm, but, seriously, robots had greater precision back in the mid 80's, One would thing that it improved over time, but I guess there is no guarantee...

Nexstar is not a high end mount. If you want a near complete absence of periodic error (corrected by high resoluti to the extent that guiding is not necessary you'll need to pay a lot more and buy one of these:
planewave.com...-GKL4E

Starred this.

Tanka, I highly suggest you listen to ngc here. He knows his stuff well!

originally posted by: tanka418
Firstly, thank you for all the help...

I found that the HabHYG table has all of what I was looking for. It contains some 3000+ BayerFlamsteed identifiers, along with HIP translations. So, I've been rewriting some of my SQL "views" t use the improved dataset. This also allows me to deploy over 117,00 stars without having to alter the datasets (add corrected RA / DECL).

In the meantime y'all, I'll continue to develop my database, and other aspects of the system.

So, um can U2U me when I can have betatest access to it?

originally posted by: JadeStar

originally posted by: tanka418
Firstly, thank you for all the help...

I found that the HabHYG table has all of what I was looking for. It contains some 3000+ BayerFlamsteed identifiers, along with HIP translations. So, I've been rewriting some of my SQL "views" t use the improved dataset. This also allows me to deploy over 117,00 stars without having to alter the datasets (add corrected RA / DECL).

In the meantime y'all, I'll continue to develop my database, and other aspects of the system.

So, um can U2U me when I can have betatest access to it?

Sure no problem...might take a couple of days yet for the database...I tend to get distracted by learning events, which are frequent right now (I'm lovin' it!)

And I am taking everything both you and NGC are saying, and integrating it...You're both very knowledgeable, and I can learn quite a lot from you.

originally posted by: tanka418

originally posted by: JadeStar

originally posted by: tanka418
Firstly, thank you for all the help...

I found that the HabHYG table has all of what I was looking for. It contains some 3000+ BayerFlamsteed identifiers, along with HIP translations. So, I've been rewriting some of my SQL "views" t use the improved dataset. This also allows me to deploy over 117,00 stars without having to alter the datasets (add corrected RA / DECL).

In the meantime y'all, I'll continue to develop my database, and other aspects of the system.

So, um can U2U me when I can have betatest access to it?

Sure no problem...might take a couple of days yet for the database...I tend to get distracted by learning events, which are frequent right now (I'm lovin' it!)

And I am taking everything both you and NGC are saying, and integrating it...You're both very knowledgeable, and I can learn quite a lot from you.

Thanks, and no rush, take your time. The most important thing in all of this stuff is double checking things, no need to rush through or hurry. I'll be here.