I tried more distant objects like Jupiter ... Neptune.
This revealed that at increasing distances, the convergence
threshold in inverse_terra needed to increased also.
So now I use 1 AU as a baseline, and scale up linearly
for more distant objects.
Asking the latitude and longitude directly beneath
the Sun causes inverse_terra not to converge, because the
convergence increment `W` never got below 1.48e-8, but the
convergence limit was 1.0e-8. I increased the limit to 2.0e-8
in all programming language versions.
I'm hoping that is a big enough tolerance for all cases now,
but I will do more testing to see if further fixes are required
for even more distant bodies than the Sun.
I propose to add some helpful information so users can easily create correct Date objects, as the JavaScript Date class can be confusing. This class contains a timestamp (the number of milliseconds since Jan 1st 1970 at midnight), which is timezone-agnostic, but the methods to interact with this number do involve timezones.
Include TypeScript type definitions in the exported files.
This might be a fix for #294, but I'm not sure.
The only real way to test is to publish on npm and see what happens!
Prevents crashes due to dereferencing NULL time pointers.
Passing in NULL for a `time` pointer will no longer cause
a crash in an Astronomy Engine function.
Wherever possible, a NULL time pointer will result in a
status code `ASTRO_INVALID_PARAMETER`.
`Astronomy_Horizon` has no way to report a status code,
so a null pointer causes it to return all NAN values.
Perhaps it should return a status code (considering for separate commit).
Thanks to [Steven Booth](https://github.com/sbooth) for suggesting this!
It turns out that GetSystemTimeAsFileTime only returns
time with millisecond resolution.
In order to get microsecond resolution in Astronomy_CurrentTime(),
I had to switch to GetSystemTimePreciseAsFileTime for Windows.
Example output from unit test:
C Test_AstroTime: PASS - realtime increment = 3.143e-07 seconds after 1 iterations.
This is a follow-up to work provided by:
Eric Wheeler, KJ7LNW <astronomy-git@z.ewheeler.org>
Before now, the C function Astronomy_GetCurrentTime returned
the current time from the system clock, but only with whole
second resolution. Now it supports microsecond resolution on
Linux/Unix, Mac OS, and Windows.
For unsupported platforms, a compiler error will occur
to indicate that microsecond resolution is not available.
However, it is possible to define one of the following two
preprocessor symbols to work around the compiler error:
1. ASTRONOMY_ENGINE_NO_CURRENT_TIME
Excludes the function Astronomy_CurrentTime from the build.
If your project does not need to obtain the current time,
or your hardware platform does not provide current date
and time in the first place, this is likely the better option.
2. ASTRONOMY_ENGINE_WHOLE_SECOND
If your project does need to use the current date and time
for astronomy calculations, and it can tolerate whole
second resolution, this option provides a version of
Astronomy_CurrentTime that uses a call to `time(NULL)`.
Notes:
- Added unit test to confirm at least millisecond resolution.
Because these tests have to run on GitHub Actions cloud platform,
and those systems can be heavily CPU-loaded, I want to be tolerant
of resolution and avoid false failures.
- Added detection of Mac platform.
- Added preprocessor options documented above.
- On Windows, use ULARGE_INTEGER and eliminated one integer division.
- Added comments and developer documentation.
- Converted tabs to spaces in astronomy.c, for consistent code format.
This patch adds support for microsecond time resolution on the UNIX and
WIN32 platforms.
Implementation details:
Previously, the `Astronomy_CurrentTime()` function used `time(NULL)` to
get the current time, thus providing 1-second resolution. This patch
uses `gettimeofday()` for UNIX and `GetSystemTimeAsFileTime()` for WIN32
platforms. If neither are supported, it will fall back to `time()` and
issue a #warning. (Note that windows.h defines ARRAYSIZE, which may or
may not be compatible. Thus, the internal define `ARRAYSIZE` is renamed
to `ASTRO_ARRAYSIZE`.)
The UNIX code was tested in Linux, and in arm-eabi-none under newlib.
The WIN32 code was tested using MinGW/64 under WINE.
Use case:
One-second resolution is enough in most cases. However, there are cases
where higher resolutions are desirable. For example:
We are using the astronomy.c library to control a mechanical rotor to
track celestial objects (planets, stars, and satellites). The rotor
controller uses a PID controller with 100 tick/sec updates, and tracks
the velocity of the azimuth and elevation angles from the previous tick.
With 1-second resolution, the PID controller jerks and oscillates once
per second as it adjusts to the new position. With at least
10-millisecond resolution (100/sec), it can calculate the per-tick
velocity change and track smoothly with far less jitter.
More information about the project:
Source using astronomy.c:
https://github.com/KJ7NLL/space-ham
Lego-controlled az/el:
https://youtu.be/vrlw4QPKMRY
Lego-controlled telescope focus:
https://youtu.be/p-5dOQG95xg
APID+SMC control algorithm:
https://doi.org/10.1016/j.precisioneng.2022.01.006
Signed-off-by: Eric Wheeler, KJ7LNW <astronomy-git@z.ewheeler.org>
Tested-by: Zeke Wheeler, KJ7NLL <kj7nll@gmail.com>
On the Raspberry Pi 4, using latest versions of cppcheck
and pylint, a few more minor fixes were needed for eliminating
warnings.
Also had to soften a tolerance for the Kotlin unit tests.
Slightly different cppcheck dev 2.11 behaviors have added
another warning that I don't care about. I don't want to
have to convert callback pointers to const, then cast them
to const.
However, it did find a couple of useful cases I fixed in
astronomy.c where GravSim parameters could be made const.
Because I plan on adding metersAboveGround as a parameter
that defaults to 0.0 in the other languages, and I want
the language implementations to be reasonably consistent,
I moved the metersAboveGround parameter to the end of
the parameter list for the C version of SearchRiseSetEx.
I realized I had to rework the RiseSetEx function so that
it accepts a height above ground level, rather than a generic
altitude angle correction, because atmospheric effects are
important both for the horizon dip angle and for the amount
of refraction at ground level.
The atmosphere calculations were interesting enough that
I made them public as a new function Astronomy_Atmosphere.
This returns the idealized temperature, pressure, and relative
density of air at the given elevation above/below sea level.
This is the first step toward calculating body rise/set times
for an observer that is significantly above the ground.
It figures out the angular correction of the horizon
using both parallax and refractive correction of a light
ray from the horizon to the observer's eye.
Enhanced the Time class to correctly calculate calendar
dates for the year range -999999 to +999999.
Made unit tests in C, C#, and Kotlin all exercise
the full year range, for February 28 and March 1 in each year,
to make sure we cover before and after each potential leap day.
The C functions for calculating calendar dates used the
type `long` to perform calculations that require 64-bit
integers. However, in some C compilers, `long` is still
32 bits. This caused a failure in Windows for extreme
year values. So I now use the type `int64_t` to explicitly
require a 64-bit integer.
Applying the same recent fixes to C and C# to the Python code.
I'm also changing my philosophy of representing times.
From now on, they will be truncated to the floor millisecond,
not rounded to the nearest millisecond. This means we don't reach
another calendar date until we have had 60 full seconds after
the last minute. Otherwise there is too much nasty logic for
rounding up calendar dates. I will follow suit across all languages.
Fixed problems converting AstroTime to calendar dates and back.
Also expose struct CalendarDateTime to outside callers,
for convenience dealing with Gregorian calendar dates.
With more rigorous testing, I discovered more bugs
in the C functions for converting calendar dates
to times and vice versa.
Astronomy_UtcFromTime():
When the year went before -4714, the value of the variable
`djd` went negative, causing the typecast `(long)djd` to
round toward zero instead of taking the true floor.
Changed this to `(long)floor(djd)`.
Astronomy_MakeTime():
Reworked the logic so that none of the integer divisions
involve negative values over the year range -999999..+999999.
Addressed limitations of the logic I copied from NOVAS cal_date().
Its formulas did not work for years much before -12000 due to
integer division going negative. I figured out how to make the
formulas work for plus or minus 1 million years from the present era.
Implemented and added tests for the following methods:
AstroTime.TryParse()
AstroVector.TryParse()
I still need to implement StateVector.TryParse().
Fixed a bug in CalendarDateTime: the NOVAS cal_date
function worked well, except when years go below
somewhere near -12000. Then the formulas start making
negative numbers, which messes up the calculation
of the month and day.
So to fix this, I figured out that any multiple of
400 years added to any calendar date gives the exact
same calendar date. And 400 years always has the exact
same number of days in it: 146097.
Because one million years = 400 * 2500 years, I can
add 2500*146097 days at the front of the formula
and subtract 1000000 years at the back, and everything
works for the entire range of years plus or minus
one million years from the present.
Because my date format allows for no more than a 6-digit
decimal year, this is perfectly adequate.
Replace the abstract class with a parameter of function type.
This allows the documentation to fully explain how to use
`CorrectLightTravel` without having to look at the code.
