CFE_TIME_GetTime() information seems incorrect?

[SweeWarman]

A question related to the use of the time service provided by cfe.

I am trying to get time information using the API provided by cfe as follows:

CFE_TIME_SysTime_t time;
time = CFE_TIME_GetTime();

And I print it as follows:

char buffer[500] = {0};
CFE_TIME_Print(buffer,time);
OS_printf("%s\n",buffer);

But the printed year and time information seems to be incorrect. It indicates some value in 1980 as: 1980-012-14:03:20.00000. Also, when I launch cfe (core-cpu1), I see the following output which indicates the time starting in 2030 and then changing to some value in 1980.

2030-069-17:55:07.13648 SB internal message format: CCSDS Space Packet Protocol version 1
2030-069-17:55:07.13649 ES Startup: Calling CFE_TIME_EarlyInit
1980-012-14:03:20.00000 ES Startup: Calling CFE_TBL_EarlyInit
1980-012-14:03:20.00021 ES Startup: Calling CFE_FS_EarlyInit

Could someone please explain how I could obtain the correct current time information using the cFE APIs without having to resort to using functions in time.h?

Thanks!

[jphickey]

correct current time information using the cFE APIs

This depends on what is considered "correct" ....

The CFE_TIME functions do not directly use the CPU's real time clock. Rather, CFE TIME tracks a notion of "MET" (mission elapsed time) and combines this with the "mission epoch" (CFE_MISSION_TIME_EPOCH_YEAR, CFE_MISSION_TIME_EPOCH_DAY, etc) and the spacecraft time correction factor (SCTF) to produce an estimate of "wall time".

As you noted, the default epoch is 1980, and if no SCTF is set, this is the value one will get from CFE_TIME. It expects to get a proper value for these in the incoming messages (time at tone etc).

[skliper]

If you want time from the underlying OS, see OS_GetLocalTime (and OS_SetLocalTime) that abstract time.h. Note this is typically not what missions use for general time management (cFE Time Services).

[skliper]

Note the cFE User's Guide does attempt to document mission time management and related configuration options (make usersguide from top level bundle).

[jphickey]

One possible suggestion/consideration - rather than always initializing the STCF value to zero, as it does today, it could query the PSP for the initial value.

In that case a "development" PSP like pc-linux, which almost certainly is NOT going to get time at tone signals to make it correct, could at least pre-initialize this value from the OS clock so that the log timestamps don't always just show 1980.

Other PSPs which do not have a real time reference and/or do not want to use it can continue initializing STCF to zero and relying on time at tone signals, as they do today.