Astro-satpass
view release on metacpan or search on metacpan
0.088 2018-01-16 T. R. Wyant
Iridium 34 decayed January 8 2017. So marked in canned status.
0.087 2017-12-30 T. R. Wyant
Iridium 6 decayed December 23 2017. Update canned status for this.
Kelso marks Iridium 34 tumbling, 96 partial December 22 2017. Update
canned status for this.
Kelso marks Iridiums 6, 19 & 22 as tumbling. Canned status table
updated to reflect this.
0.086 2017-12-06 T. R. Wyant
Mark Iridium 8 as decayed in canned status table.
0.085 2017-11-24 T. R. Wyant
Kelso says Iridiums 5, 8, and 51 are tumbling. Canned status updated
to reflect this.
0.084 2017-10-12 T. R. Wyant
Add support for decayed Iridium satellites:
* Carry them in canned status table
* Have can_flare( 'all' ) return true regardless of satellite
status.
from the station rather than the satellite.
* The satpass script warns every time geocoding is done if
Geo::Coder::Geocoder::US is not installed.
0.055 2012-10-27 T. R. Wyant
Workaround for problem with Date::Manip clobbering $ENV{PATH} when it
is loaded.
T. S. Kelso recorded Iridium 4 (OID 24796) as being out of service
about midnight 20-Oct-2012 GMT. I have updated the canned status,
since I know he calls Iridium LLC to get the status.
Have the Astro::Coord::ECI::TLE status() method take optional OID
arguments for the 'show' subcommand.
0.054 2012-10-09 T. R. Wyant
Correct field TLE_LINE0 in the JSON TLE generated by
Astro::Coord::ECI::TLE to include the leading '0 '.
INCOMPATIBLE CHANGE: In the JSON representaion of a TLE, the common
The satpass script's 'status iridium' command now generates a
deprecation notice every time it is issued.
0.043 2011-08-29 T. R. Wyant
The earthquake (Mineral Virginia USA) fire (Great Dismal Swamp) and
flood (hurricane Irene) edition.
Updated the canned Iridium status in Astro::Coord::ECI::TLE for
McCants' and Sladen's reporting of Iridium 26 (OID 24903) as out of
service. They also updated Iridium 23 (OID 24906) to show it in
service rather than failed, but I have continued to follow Kelso in
calling it a spare.
Other than this, only documentation changes, mostly relating to the
deprecation of the 'limb' attribute and its relation to the new
'edge_of_earths_shadow' attribute.
In the satpass script, use the new 'edge_of_earths_shadow' setting in
the 'flare' and 'position' commands, though the flare calculation
does not actually make use of it.
* Add 'backdate' parameter, propagate to pass() and flare().
* Add 'desired_equinox' parameter, use it when displaying inertial
coordinates (only equatorial, at the moment).
* Allow pseudo-redirection of command output into a pipe.
0.013 2007-03-02 T. R. Wyant
Astro::Coord::ECI 0.013:
* No code changes, but updated version to be visible to CPAN 'r'.
Astro::Coord::ECI::TLE 0.009:
* Updated canned Iridium status table for failure of Iridium 36 and
its replacement by Iridium 97.
Astro::Coord::ECI::TLE::Iridium 0.002:
* Fixed occasional borderline-case spurious flare prediction.
lib/Astro/Coord/ECI/OVERVIEW.pod view on Meta::CPAN
coordinates for Julian year 2000.
But in orbital calculations it can also be used as a proxy for the
'as-of' date of the orbital data. This is important for L<TLE|/TLE> data
because this data has a limited 'shelf life', and the farther from the
epoch you are the worse the predictions are. In extreme cases the model
itself fails because it cannot handle the type of orbit predicted.
Typically the 'shelf life' of a L<TLE|/TLE> is a couple weeks for casual
use, though data for satellites in near-Earth orbits (defined as a
period of less than two and a half hours) are usually updated every
couple days. In extreme cases (e.g. the first arc of a Space Shuttle
flight) the model may fail within a couple days of the epoch. See the
L<TLE|/TLE> documentation for more information.
=head2 OID
Short for 'Object ID', this is a unique number assigned to an object by
NORAD or its successors when the orbiting L<body|/Body> is detected. The
OID may also be called the 'Satellite ID', the 'Satellite Number', or
simply the 'ID'.
lib/Astro/Coord/ECI/TLE.pm view on Meta::CPAN
delete $parm->{init};
return $parm;
}
#* -----------------------------------------------------------------------------
#*
#* SUBROUTINE SGP4
#*
#* this procedure is the sgp4 prediction model from space command. this is an
#* updated and combined version of sgp4 and sdp4, which were originally
#* published separately in spacetrack report #3. this version follows the
#* methodology from the aiaa paper (2006) describing the history and
#* development of the code.
#*
#* author : david vallado 719-573-2600 28 jun 2005
#*
#* inputs :
#* satrec - initialised structure from sgp4init() call.
#* tsince - time eince epoch (minutes)
#*
lib/Astro/Coord/ECI/Utils.pm view on Meta::CPAN
The return is the position angle B<in radians>, in the range
C<< -PI <= $pa < PI >>.
The algorithm comes from Jean Meeus' "Astronomical Algorithms", 2nd
Edition, page 116, but his algorithm is for the position angle of the
first body with respect to the second (i.e. the roles of the two bodies
are reversed). The order of arguments for this subroutine is consistent
with The IDL Astronomy User's Library at
L<https://github.com/wlandsman/IDLAstro>, function C<posang()>. The NASA
page for this, L<https://asd.gsfc.nasa.gov/archive/idlastro/>, is
obsolete and no longer updated, but also more descriptive.
This is exposed because in principal you could calculate the position
angle in any spherical coordinate system, you would just need to get the
order of arguments right (e.g. azimuth, elevation or longitude,
latitude).
=cut
sub position_angle {
my ( $alpha1, $delta1, $alpha2, $delta2 ) = @_;
( run in 0.373 second using v1.01-cache-2.11-cpan-05444aca049 )