Star shots

i believe sokkia and the rolla, missouri engineering company stopped publishing the ephemeris books. i recommend MICA software from USNO as an alternative

RoadBurner, post: 406675, member: 6168 wrote: It's been years since I did one, but sometimes I'd like to think that I could do an hour-angle observation on a star (besides Polaris or the sun) if I wanted to. The old Sokkia handbooks were great. Is there an ephemeris online that lists the stars in the old handbooks?

Happy 2017

Mr Jerry Wahl has provided an ephemeris in recent years. The latest is 2016 and is available here:
http://www.cadastral.com/2016ephs.htm

http://www.rollanet.org/~eksi/Handbook.htm

This is the last edition of the Leitz Ephemeris.

I plan to attempt on with my HP48GX and SMI v7 card since I found my sun filters a few weeks ago.

I am sure the Ephemeris is way out of date, I was last told that some versions could update to an unknown time and other cards would end much sooner. Kinda, like they really did not have an answer.........and those people are probably not listening in......

Started using that in the late 80s to early 90s and it was closer than anyone had been able to get around here since the early surveyors that used the solar transit.

Only exception were the Polaris shots

Our county lines are off 1deg from N,S,E,W

In 2005 according to GNSS Solutions in WGS84 found out most every sunshot off approximately 40+seconds due to the difference in satellite time and real time.

Current officer training in the USN requires training to use a sextant. Makes you wonder doesn't it.

Floyd Carrington, post: 406738, member: 474 wrote: Current officer training in the USN requires training to use a sextant. Makes you wonder doesn't it.

It works even if the international situation deteriorates. I wish more systems had backups in place. See a thread a while back about vulnerability of many systems (cell phones, 911 service, etc) if they lost GPS time.

Major stars sun and planets GHA. declination.
This is what you want. I use this site a lot for star and sun shots. You can get year long, 0hr GMT ephemeris in ascii. Plenty of stars, not just Polaris.

http://aa.usno.navy.mil/data/docs/geocentric.php

Thanks, Larry 🙂

A Harris, post: 406728, member: 81 wrote: In 2005 according to GNSS Solutions in WGS84 found out most every sunshot off approximately 40+seconds due to the difference in satellite time and real time.

Can you elaborate on that a bit. A properly done celestial observation should produce a geodetic azimuth that will be very close to a the GPS derived azimuth of a line that most GNSS software will label as "WGS84" azimuth if you don't have a grid projection attached ie: State Plane or UTM, etc..

It sounds more like a grid vs geodetic azimuth issue or are you saying the sunshots were reduced with something other than UT1 producing an azimuth error of 40"?

Shelby H. Griggs PLS, post: 407115, member: 335 wrote: Can you elaborate on that a bit. A properly done celestial observation should produce a geodetic azimuth that will be very close to a the GPS derived azimuth of a line that most GNSS software will label as "WGS84" azimuth if you don't have a grid projection attached ie: State Plane or UTM, etc..
It sounds more like a grid vs geodetic azimuth issue or are you saying the sunshots were reduced with something other than UT1 producing an azimuth error of 40"?

For a long time, the source of time was so far off that was causing the great error.

Shelby H. Griggs PLS, post: 407115, member: 335 wrote: Can you elaborate on that a bit. A properly done celestial observation should produce a geodetic azimuth that will be very close to a the GPS derived azimuth of a line that most GNSS software will label as "WGS84" azimuth if you don't have a grid projection attached ie: State Plane or UTM, etc..

It sounds more like a grid vs geodetic azimuth issue or are you saying the sunshots were reduced with something other than UT1 producing an azimuth error of 40"?

See:
https://www.ngs.noaa.gov/CORS-Proxy/Glossary/xml/NGS_Glossary.xml

A Harris, post: 407116, member: 81 wrote: For a long time, the source of time was so far off that was causing the great error.

what?? if someone was erroneously using GPS time rather than UTC the error would be WAY larger than 40". We have had access to accurate time using radio signals since around 1962. Using a simple time cube or shortwave radio one could get time to a fraction of a second. 1s time=15 arc seconds of longitude, so if using time accurate to 0.5s (easy to do), worst case is 7.5". Before radio time signals there was the telegraph. Before that one could get accurate time by observing various stars (meridian transits, etc). I started doing solars around 1982, and I know I was getting better than 10" using a time receiver, stopwatch, and a T2.

Could you post a link to that article you are referencing?

GeeOddMike, post: 407125, member: 677 wrote:

See:
https://www.ngs.noaa.gov/CORS-Proxy/Glossary/xml/NGS_Glossary.xml

Mike, correct and I understand the definitions, but as long as you compare a solar geodetic az and one from GNSS at the same location you shouldn't see 40" difference. I realize WGS84 is also probably not what it is, only being labeled that by software. Typically from experience, they will agree within a few seconds if comparing apples to apples.

SHG

John Hamilton, post: 407135, member: 640 wrote: what?? if someone was erroneously using GPS time rather than UTC the error would be WAY larger than 40". We have had access to accurate time using radio signals since around 1962. Using a simple time cube or shortwave radio one could get time to a fraction of a second. 1s time=15 arc seconds of longitude, so if using time accurate to 0.5s (easy to do), worst case is 7.5". Before radio time signals there was the telegraph. Before that one could get accurate time by observing various stars (meridian transits, etc). I started doing solars around 1982, and I know I was getting better than 10" using a time receiver, stopwatch, and a T2.
Could you post a link to that article you are referencing?

The error could have been an out dated Ephemeris on the SMI cards we were using.

The company beta tested cards and we really never knew what card the boss had installed unless we changed the batteries.

We would coordinate time in the office most every morning and was based upon a time cube that I never saw.

there could be an issue where an on board ephemeris may get less accurate as time goes on, in order to maintain accuracy over long periods you must use complicated algorithms with a lot of parameters. However, if you use something like MICA then accuracy should be consistent. Using a correct value of DUT1 and knowing the Delta T values (longer term) is of course critical. Here is a prediction of Delta T. Note that the error gets fairly large for years that are further in the future.

YEAR TT-UT PREDICTION UT1-UTC PREDICTION ERROR

2016.75 68.51 -0.330 0.02
2017.00 68.66 -0.472 0.06
2017.25 68.8 0.384 0.1
2017.50 69.0 0.232 0.2
2017.75 69.1 0.2
2018.00 69.2 0.3
2018.25 69.4 0.4
2018.50 69.5 0.4
2018.75 69.7 0.5
2019.00 69.8 0.7
2019.25 69.9 0.8
2019.50 70.0 0.9
2019.75 70. 1.
2020.00 70. 1.
2020.25 70. 1.
2020.50 71. 1.
2020.75 71. 2.
2021.00 71. 2.
2021.25 71. 2.
2021.50 71. 2.
2021.75 71. 2.
2022.00 71. 2.
2022.25 71. 2.
2022.50 71. 3.
2022.75 72. 3.
2023.00 72. 3.
2023.25 72. 3.
2023.50 72. 3.
2023.75 72. 3.
2024.00 72. 3.
2024.25 72. 4.
2024.50 72. 4.
2024.75 73. 4.
2025.00 73. 4.
2025.25 73. 4.
2025.50 73. 5.
2025.75 73. 5.
2026.00 73. 5.
2026.25 73. 5.
2026.50 73. 5.

After the fact, Delta T can be gotten with high accuracy:
2015 1 1 67.6439
2015 2 1 67.6765
2015 3 1 67.7117
2015 4 1 67.7591
2015 5 1 67.8012
2015 6 1 67.8402
2015 7 1 67.8606
2015 8 1 67.8822
2015 9 1 67.9120
2015 10 1 67.9546
2015 11 1 68.0055
2015 12 1 68.0514
2016 1 1 68.1024
2016 2 1 68.1577
2016 3 1 68.2044
2016 4 1 68.2665
2016 5 1 68.3188
2016 6 1 68.3703
2016 7 1 68.3964

Because of this, it is difficult to make a "hard coded" ephemeris for dates way in the future, because of the variability in the Length of Day (LOD) and leap seconds.

A Harris, post: 407158, member: 81 wrote: The error could have been an out dated Ephemeris on the SMI cards we were using.

The company beta tested cards and we really never knew what card the boss had installed unless we changed the batteries.

We would coordinate time in the office most every morning and was based upon a time cube that I never saw.

40" of arc would be about 2.5" of time, the process used to be to listen for the time stamp on the radio (that is how one surveyor I worked for did it back in the day), later we would call up the site in Colorado. You check your watch to the time and off you go. Anyway, 2.5" back in the day was easy to pick up, but it should be fairly random. Add to that plotting your NAD27 position on a quad, and well, 40" doesn't seem all that terrible. I know I did better than that by checking to State Plane monuments, but once I got GPS I quit doing any, haven't done one since 1996.

John Hamilton, post: 407160, member: 640 wrote: there could be an issue where an on board ephemeris may get less accurate as time goes on, in order to maintain accuracy over long periods you must use complicated algorithms with a lot of parameters. However, if you use something like MICA then accuracy should be consistent. Using a correct value of DUT1 and knowing the Delta T values (longer term) is of course critical.

Because of this, it is difficult to make a "hard coded" ephemeris for dates way in the future, because of the variability in the Length of Day (LOD) and leap seconds.

Why would you need to? If you're making observations and reducing the numbers, you're doing it now, not way in the future. Entering the DUT is a single entry, and not very hard to change/update. Not sure I understand the issue.

rfc, post: 407162, member: 8882 wrote: Why would you need to? If you're making observations and reducing the numbers, you're doing it now, not way in the future. Entering the DUT is a single entry, and not very hard to change/update. Not sure I understand the issue.

The issue is that someone created an program on ROM for an HP41 (or maybe it was the HP48). It was accurate when it was made way back when, but the further away you get the more error is introduced. I should point out that Delta T is NOT the same as DUT. It is a combination of DUT and leap seconds. Leap seconds are not totally predictable very far in the future, so the "hard coded" program can use DUT as an input, but I don't think there was any way to give it the number of leap seconds.

Here is an explanation of Delta T:
http://davinci.asu.edu/index.php?title=DeltaT

40+ seconds in time due difference in GPS and actual time
40 seconds in bearings difference that I am not sure of the source of error.

The HP41 had the best built in clock routine ever. Every time it was corrected it kept better time. Over a few years of use, the clock would keep real time for weeks, as long as the source of real time was actually real time.

The expansion of memory and programming made to create the HP48 left out room for the great time routine the HP41 had.

The owner of the company I worked at claimed time came from a time cube and I really think it was from the Weather channel or some similar source.
We always scale our latitude and longitude from USGS Topo Quads.

Got my first handheld Garmin when the III Plus came out and used that as a source of time and location for SMI on HP48GX until I learned Garmin was off by 40+ seconds in time according to the atomic clock.

Then I got a clock that received corrections from the atomic clock.

Those signals are random and may actually correct the clock a couple times a year and the changes made for Daylight Savings change dates really mess with it.

Currently my phone clock is 37 seconds different in time that the Atomic Clock according to Navy Clock app (0.north-america.pool.ntp.org). I understand it is off a digit or two because of GPS communication lag.

My solutions with GPS in WGS84 is 40+ seconds different in bearings and azimuths computed from all those past sunshots made using the wrong time.

WGS84 results have always agreed very closely to Polaris references I have checked into and SMI sun shot information when using the correct time.