More low-level functions necessary to calculating Earth orientation.
iau2000b calculates nutation angles.
etilt calculates overall axial tilt of the Earth.
era calculates the Earth Rotation Angle.
I'm working toward implementing the GeoMoon function.
I added the following, which are all required to get to that point.
meanObliq
eclOblToEquVec
eclToEquVec
precessionRot
precession
RotateVector
Added the function CalendarFromDays, which converts a UT value to
a calendar date and time.
Added script `rungo` which is a shortcut for compiling and testing
changes to the Go source code template.
Added functions:
DegreesFromRadians
RadiansFromDegrees
AngleBetween
StateVector.Position
StateVector.Velocity
Changed existing functions to pass structs by value,
just like we do in the C code. This is a safety feature
to signal value semantics and a contract not to mutate the
argument state.
Run Go tests with the -v option to log more info about what's happening.
Added SVG logo for Go.
Added a table entry for Go examples, source, and documentation.
Sorted the language list in alphabetical order: moved Python last.
I need gomarkdoc to generate identical output whether
I run it locally or in GitHub Actions, to verify that the
build process is working correctly. Hopefully these options
will do the trick.
Following the standard comment format for documentation
comments in Go:
https://go.dev/doc/comment
Later we will figure out how to generate online documentation
from these comments.
In Go, all symbols should use PascalCase or camelCase.
Go programmers dislike ALL_UPPER_CASE_WITH_UNDERSCORES.
Use PascalCase for exported/public symbols, camelCase for internal/private symbols.
In general, we should follow the Go Style Guide:
https://google.github.io/styleguide/go/index
I recommend we more closely follow the implementation of the C# code
than the C code for figuring out how to name things.
The C# version of Astronomy Engine is a better reference because
Go allows quasi-object-oriented syntax and uses a similar preferred naming style.
We will use idiomatic error reporting and handling, as described here:
https://go.dev/blog/error-handling-and-go
I removed the "status" fields from all the structs, and deleted
the enumerated type astroStatus. I will add a custom error type later,
and report human-readable error messages as is preferred by Go programmers.
Rework astronomy.go as a module named "astronomy".
Provide a go.mod to define the module.
Add Go as a known programming language to the code generator.
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.
