I've written an App for calculating Greenwich Mean Sidereal Time using the clock get millisecond component which reads a mobile phone to supply the number of milliseconds since 1970. The app seems to work well but is consistently two minutes ahead of the Greenwich Sidereal Time displayed by Heavens Above (https://www.heavens-above.com/). I've been using a US Navy calculation at Sidereal Time and my app is shown below with the aia in a link. Is it possible the clock in my phone is inaccurate or is there an inaccuracy in the Clock component? The US Navy are quite specific that the errors in their equation are less than a second.
I'm using the standard astronomy julian day reference JD2000 so I'm subtracting the difference between JD2000 and JD1970 from the 1970 clock measurement. That part of the calculation works fine.
Android phone timing is synchronised with atomic clock-based GPS data whenever the phone is turned on. The naval GMST algorithm I'm using has an accuracy of a fraction of a second. The Android clock data does have a known 15 s non-cumulative error due to an uncorrected software glitch event in 1982. But I'm not aware of any other 120 s or 115 s error since 1970. So I can't see that the error is cumulative and this seems to be an error of 2 minutes over 24 hours in the Clock component unless the JD1970 value is flawed.
It's entirely possible I'm missing something and I can put in a systematic correction as there is nothing crucial about my application. However, I've learned that simple errors can sometimes hide fundamental problems so thought it was worth asking.
You use a longitude of 151.1473 in your sidereal equation. Is this the longitude Heavens Above uses when you make your comparison? Perhaps the longitude needs more precision (an additional decimal place) to be compatible with Heavens Above assumptions?.
You compared your results against Heavens Above, did you also compare your calculation with the usno.navy.mil siderealtime calculator you mentioned?
Many thanks for all the suggestions. I've added a UTC clock to the App and checked them all as follows:
ABG: * When you say two minutes, exactly how many seconds or milliseconds is that?
PO: 1m 58.45766s for one test measurement
ABG: * Inexact data types (floating point intermediate calculation variables)
PO: I can't comment on this and not sure how to test for the possibility as I'm using decimal numbers in the app. But it, or the possibility of rounding errors somewhere, sounds plausible
ABG: * Geographic anomalies (non-spherical Earth, location dependencies)
PO: Almost certainly no as the calculation is for GMST rather than LMST
ABG * Time shifts (cumulative Einsteinian relativistic satellite time differences)
PO: Could be satellite time differences but I doubt if they would be Einsteinian relativistic. I think that would require much greater distances.
ABG: * Time signal travel time (a foot is a nanosecond)
PO: I don't think this could be the case even if the errors were cumulative i.e. if the refresh function has not been used by Unix since J1970, as the satellites are too close and not enough time has elapsed since the late 70's when GPS satellites were first being tested. It might be an earth-bound transmission line problem though.
Steve JG: You use a longitude of 151.1473 in your sidereal equation. Is this the longitude Heavens Above uses when you make your comparison? Perhaps the longitude needs more precision (an additional decimal place) to be compatible with Heavens Above assumptions?.
PO: The longitude was identical for my App and Heavens above (my longitude is registered with them). The precision matches the USMil site precision but I increased it anyway for future LMST checks as it could well be that the problem is one of precision somewhere. However longitude is only relevant for LMST. The GMST is for a fixed location
SteveJG: *You compared your results against Heavens Above, did you also compare your calculation with the usno.navy.mil siderealtime calculator you mentioned?
PO: I added a UTC clock and checked as you suggested against the USNavy site. The difference is the same as for Heaven's above and at the time of writing was measured as 1m 58.45766s
Juan Antonio Change JD1970-JD2000 by JD2000 -JD1970
PO I used a double negative because it was a correction to a standard subtraction - just two ways of looking at the same equation.
I've really appreciated all the feedback and so far it seems as if the problem is either some kind of earth-bound time signal transmission problem, or a failure in management of the Unix time clock, or some kind of rounding error somewhere. However, Its a very simple equation and I've kept the precision of constants and variables identical to the US Navy precisions. And apart from the USNavy numbers the only other variable is the J1970 Clock millisecond value and the well known J2000 value.
Agreed Juan You are absolutely correct. I misinterpreted how the J2000-J1970 should be applied. I also get a 6.5 s error which I don't understand as its larger than the error USNavy predict for this approximation, but I'm told the Android version of J1970 does have a couple of errors that have not yet been corrected and a few seconds won't affect my application.
Many thanks to you all and apologies for consuming so much of your time on that error.
Attached is a copy of the revised App that includes Juan's correction, and is set up to implement Steve's suggestion for comparison against the US Navy sidereal clock display https://aa.usno.navy.mil/data/siderealtime. So it now includes a UTC clock output and a button to take snapshots of the App output. The RA (right ascension) output is also now set up for LMST rather than GMST.
