Timing Precision Modes

Top  Previous  Next

FreeFlyer allows users to create Mission Plans in two separate timing precision modes. Nanosecond precision mode stores all time values to nanosecond-level precision, and millisecond precision mode stores all time values at millisecond-level precision.


The timing precision mode for every FreeFlyer Mission Plan is set when the Mission Plan is created, and cannot be changed. A Mission Plan created in one mode cannot be opened in the other mode. Nanosecond precision mode was introduced in FreeFlyer 7.1, and became the default mode for newly created Mission Plans as of FreeFlyer 7.3. Mission Plans can still be created in either mode using the drop-down menu on the "New Mission Plan" button, as shown in the image below.



Nanosecond precision mode provides higher accuracy for orbit propagation and orbit determination, and lower achievable integration error tolerances. Nanosecond precision mode is ideally suited for high precision orbit determination, especially when light-time corrections are modeled, and for deep-space propagation and maneuver planning. Any analysis that requires a very low error in propagation, or uses any input data (e.g. orbit states or measurements) specified at the millisecond level or smaller should use nanosecond precision mode.


This page provides a complete guide to working with times in each precision mode, and the steps to take to convert a Mission Plan from millisecond to nanosecond precision mode.



Working with times in each Precision Mode

The most notable difference between the nanosecond and millisecond precision modes is how time values are stored. In nanosecond precision mode, times are stored in TimeSpan objects. In millisecond precision mode, times are stored in Variable objects. FreeFlyer uses the specialized TimeSpan object type to store nanosecond-precision time values because it would not be possible to store an epoch at nanosecond-level precision in the FreeFlyer Variable object type, due to the limited numerical precision of floating point 64-bit values. In nanosecond mode, any property, method, or function that has a time value as an input or output will use the TimeSpan or TimeSpanArray object types. The table below highlights the key syntax differences when working with times in each timing precision mode. The TimeSpans page provides additional syntax examples.


The next section on this page details the other differences between nanosecond and millisecond precision mode.



Nanosecond Mode

Millisecond Mode

Time Storage Object



Elapsed Time Methods

TimeSpan = Spacecraft.ElapsedTime

Variable = Spacecraft.ElapsedDays

Variable = Spacecraft.ElapsedHours

Variable = Spacecraft.ElapsedMinutes

Variable = Spacecraft.ElapsedSeconds

Elapsed Time From Epoch Methods

TimeSpan = Spacecraft.ElapsedTimeFromEpoch(TimeSpan)

Variable = Spacecraft.ElapsedDaysFromEpoch(Variable)

Variable = Spacecraft.ElapsedHoursFromEpoch(Variable)

Variable = Spacecraft.ElapsedMinutesFromEpoch(Variable)

Variable = Spacecraft.ElapsedSecondsFromEpoch(Variable)

Calendar Date Handling Methods

String = TimeSpan.ConvertToCalendarDate()

TimeSpan = String.ParseCalendarDate()

String = Variable.EpochFormat()

Variable = String.EpochScan()

FreeFlyer Ephemeris Support

FreeFlyer Ephem v3


FreeFlyer Ephem v2

FreeFlyer Ephem v3


Literal Definition of Time

TimeSpan twoDays = TIMESPAN(2 days);

Variable twoDays = 2;


Note that the single Spacecraft.ElapsedTime method has replaced the separate Spacecraft.ElapsedDays/Hours/Minutes/Seconds methods, because the TimeSpan object provides interfaces to get or set the time value in various units of time.


Note: For ephemeris file formats that do not support sub-millisecond precision, epochs will be rounded to millisecond precision before being put to file regardless of timing precision mode.



Converting a Mission Plan to Nanosecond Precision Mode

Users who have Mission Plans in millisecond precision mode that they would like to convert to nanosecond precision mode will need to follow the steps listed below. The two modes are completely independent from one another, and there is no automated way to convert between modes.


1.Remove all deprecated functionality from your Millisecond-Mode Mission Plan

Nanosecond precision mode does not support deprecated functionality that was present in millisecond precision mode. Run your Mission Plan in Millisecond Mode and follow the recommendations in each deprecation warning to replace outdated features with the newer, recommended syntax.


2.Create a new Mission Plan in Nanosecond Precision Mode


3.Copy all FreeFlyer Script, Mission Sequence Elements, and Objects to the new Mission Plan

Mission Plans written fully in FreeFlyer Script are the easiest to convert. You can convert one or more Mission Sequence elements into FreeFlyer Script by right-clicking them and selecting "Convert Selected to FreeForm".

Objects created in the Object Browser must be re-created in the Object Browser (or in FreeFlyer script if preferred) in the new version of the Mission Plan.

Also, be aware that object presets and object files created by the Put command are not compatible between timing precision modes.


4.Handle any instances of unsupported syntax

Some script syntax that was supported in millisecond precision mode is not supported in nanosecond precision mode, because more modern and robust interfaces are now available for that functionality. If you are still using any of the following older script syntax, you will need to update your Mission Plan; otherwise it will not run successfully.

oChild objects created in the object browser can no longer be accessed using the underscore syntax such as "Spacecraft1_Sensor1." To access child objects created in the object browser or FreeFlyer script, use syntax such as "Spacecraft1.Sensors[0]."

oYou may no longer use the "Agent" command to define Procedures. You must use "Procedure" instead.

oThe "~=" operator is no longer supported for conditional comparisons; use "!=" instead.

oA single "=" sign can no longer be used as an operator to test for equality, now you have to use the "==" operator.

oObject instance prefixes must be applied to properties and methods being reported to output windows.

oSome previously available built-in global Variable objects such as MJ2000_EARTH_EQUATOR are no longer available.

oThe default Array size is now 0 instead of 10.

oArray object methods have been overhauled to more closely resemble those in standard programming languages. For example, the Array.Add() method has been removed and the recommended approach is to use Array.PushBack().

oThe "without reset" keyword combination associated with For loops has been removed, and now all For loops automatically behave as if they have that keyword combination by default. If you wish to continue using the resetting behavior, you may now use a "with reset" keyword combination in your For loop. See the properties and methods with a state page for more information.

oThe Create command keyword no longer exists. Objects should be created by simply typing the object type at the beginning of a line of code.

oYou can no longer "Report As Xml" or "Report to ReportDesigner", as these behaviors are no longer supported.

oThe "showing" keyword is no longer valid with OutputWindow constructors to specify objects. Instead, the standard constructor syntax with parenthesis should be used.

oThe FuzzySet object is not supported in nanosecond precision mode. Standard conditional logic should instead be used as needed.

oThe "Name" property of all objects has been replaced with "DisplayName" for clarity. CelestialObject objects will use the new "BodyName" property for its look-ups instead of the "DisplayName". In addition, there is now a "DeclaredName" property that can be used to determine the name of the object when it was declared in script.

oYou can no longer have multi-line literal strings in FreeFlyer script (that is, strings containing literal newlines). To include a newline in the value of a String object or property, use the syntax @"\n" as discussed on the Scanning Literal Strings section of the Parsing String Data page.

oThe "with RuntimeSetup" keywords used by targeting loops are no longer necessary. All targeting loops now automatically use the runtime setup behavior.

oThe "as Global" keyword used in association with the Put command associated with the Ephemeris and OutputWindow objects no longer exists.

oUsing the Call command for purposes of sending SQL to a database now no longer supports SQL directly inside of square brackets. You must use a String or VirtualString object in place of that syntax now.


5.Replace all Variable Instances of Time with TimeSpans

This is described in more detail in the section above. All cases where time is treated as a Variable must now use a TimeSpan instead.

If you are using the FreeFlyer Ephemeris format in version 2 or lower, you will need to step up to version 3 in order to retain nanosecond-level precision in your ephemerides.


6.That's it!

Once you've completed the above five steps, your Mission Plan should be ready for execution in nanosecond precision mode. If you have difficulty with this process, remember that you can contact FreeFlyer Technical Support for help.



See Also


Parsing Dates and Times