What to do with the "time (absolute)" information in fault codes?

[e-raser]

I´m pretty new to GS-911 but using other software like VCDS for years.

In fault codes there´s a mileage information when the fault code was recorded.

BUT what to do with the "time (absolute)" information? I translated it back from my German user interface.

It´s not a unix time coding, no unsplitted date coding, not dating back related to production date, there´s just no obvious pattern to use and convert this information at all. So:

What coding does the time (absolute) data field have?

I want a date and time, no numbers like "6081602", "214748364" or "4770462". Nothing in the FAQs so please guide me... thanks 

[C5roki]

It is something with seconds:
I had engine hickups approximately
at 2023-02-06 08:00 -> absolute time 11.753.567
at 2023-02-13 19:00 -> absolute time 12.399.565

The difference is
645.998

The number of seconds in 7 days and 11 hours is
(7*24+11)*60*60 is
644.400

Counting back that would make absolute time 0
29 September 2022

And I can't relate that date to anything that happened to the bike
- the bike is made 16 Januari 2011
- the last maintenance was 6 December 2022

Anybody ideas about "absolute time 0"?

[abdullah]

I´m pretty new to GS-911 but using other software like VCDS for years.

In fault codes there´s a mileage information when the fault code was recorded.

BUT what to do with the "time (absolute)" information? I translated it back from my German user interface.

It´s not a unix time coding, no unsplitted date coding, not dating back related to production date, there´s just no obvious pattern to use and convert this information at all. So:

What coding does the time (absolute) data field have?

I want a date and time, no numbers like "6081602", "214748364" or "4770462". Nothing in the FAQs so please guide me... thanks 

The UNIX Epoch Time (time_t) is also known as UNIX time or POSIX time. The UNIX Epoch Time indicates the number of seconds that have passed since 01.01.1970 00:00:00 UTC.





"6081602", "214748364" or "4770462" if you convert these numbers you will get some time around 1970's thats because any modern computer system if time and date are not define its automatically will use predefine date so application or system not to crash or throw errors

to know absolute time ensure that battery in your gs911 is fresh and hold charge to keep clock and time properly set then use obselete date to refere back to your that date and time your error in ecu are occur

[C5roki]

Epochs was indeed the first thing I thought too, but if it would be epochs, then

absolute time 12.399.565 (in seconds) is
24 May 1970

and that has no (obvious) relation to the log date
13 February 2023

Are there other ideas about "absolute time 0" in relation to logging of the bike / GS-911 ?

[NH1200c]

I'm thinking that the Absolute Time (or Time) entries are significant only in the context of which Controller reports them, and have no relationship to time of day or other time system references.

I am led to that conclusion based on time numbers decreasing (in the Autoscan report) from the Keyless Entry controller as Odometer readings have increased, and also the different time values reported from different controllers when the Odometer readings are relatively close together.

Sure wish someone from HEX would give us some data on these time fields in the reports.

Larry

[Ruan]

I'm thinking that the Absolute Time (or Time) entries are significant only in the context of which Controller reports them, and have no relationship to time of day or other time system references.

I am led to that conclusion based on time numbers decreasing (in the Autoscan report) from the Keyless Entry controller as Odometer readings have increased, and also the different time values reported from different controllers when the Odometer readings are relatively close together.

Sure wish someone from HEX would give us some data on these time fields in the reports.

Larry

Hi Guys

Just to add to this, we report the values that is provided with the bike. Our findings also concludes that this is most likely just a value that is available. We've looked at it a bit, but not as a high priority, to see whether it might be a value that needs an interpretation of some sort which we can develop to display those values correctly.

Although we will get to it at a later stage, currently the values given by the ECU's seem quite irrelevant.

Kind regards
Ruan

[NH1200c]

Thank you Ruan for that perspective and insight.

Larry