PEAK-System Forum

I am using Windows 10, C# and PCAN Basic API dll 4.4

I have software which needs to get the timestamp of the received CAN message. The timestamp should be the time measured from the initialization of the CAN interface. I understand that the TPCANTimestamp gives the time elapsed from the booting of the Windows system. So when I initialize the device I get the init timestamp by:

Code: Select all

 _systemUptimeAtInitCan = TimeSpan.FromMilliseconds(Environment.TickCount64);

When I receive a message I get the message timestamp with:

Code: Select all

private void OnDataFrameReceived(TPCANMsg msg, TPCANTimestamp timestamp)
{
	var messageTimestamp = TimeSpan.FromMicroseconds(timestamp.micros + (1000UL * timestamp.millis) + (0x100000000UL * 1000UL * 	timestamp.millis_overflow)) - _systemUptimeAtInitCan;

        //other code
}

But there is a problem, TPCANTimestamp gives me the timestamp with a random offset, sometimes a couple seconds or a minute. This offset changes only when I reset my computer. For ex. I am using a PCAN-USB device connected to another device which sends messages periodically from the BusMaster software every 100ms, When I initialize the peak device it instantly receives a message since the other device is transmitting periodically all the time. And the calculated messageTimestamp is 1 minute and 5 seconds, but only lets say max 1 second passed from the initialization of the device to the reception of the message. Is there something I can do to solve this issue?

Hello,

Note the following:

You are using "Environment.TickCount64" to get a timestamp in milliseconds. This is based on the Windows API function "GetTickCount" which is not accurate enough to work with (~16 milliseconds). You need to work with high performance timers with a resolution < 1 µs, as you are working in microsecond ranges.
You are creating then another TimeSpam using microseconds, so the accuracy of both TimeSpams is different.
Then you are subtracting them. I think (not sure) that in this case rounding are made, and even the microsecond part is not taken into account at all --> see attached picture.

To avoid accuracy problems, you can go two ways in my opinion:

You can use the NuGet package PCAN-Basic.NET, which provides a SystemTimestamp class to get the elapsed system time using high resolution, or
You can use the Stopwatch class, which is based on the Windows API function "QueryPerformanceCounter".

Having the value of any of the two options in microseconds as your start-time, then convert each TPCANTimestamp also in microseconds (as you are doing), and substract those microsecond values, before converting them into a TimeSpam.

Thank you for your reponse and for spotting that my timestamps were inacurate in the miliseconds range.

But the accuracy in the milisecond range is not my main concern here. The big problem is the unpredictable behaviour of the pcan timestamp. It returns the wrong wrong time elapsed from the system start. When I restart the windows pc the issue is gone, but when I just shutdown the computer and then turn it on the offset appears.

example:
pcan timestamp (system up time) 00:27:54:658...
system uptime (from Environment.TickCount64) 00:27:49:5620

I verified the system uptime by looking at the task manager and it matches in the seconds range(the task manager does not show miliseconds). But as you can see the pcan timestamp has an offset of 5 seconds. And this offset changes everytime I turn off/on my pc. But a restart removes the offset.

As Keneth wrote - do not use the "getTickCount" Counter - this is the wrong reference !
Use the Windows PerformanceCounter Class - these are exact/precise enough. And so we also use this as time base.

I tried using the performance counter, I wrote this snippet just to check if there is an offset.

Code: Select all

var peakTime = TimeSpan.FromMicroseconds(timestamp.micros + (1000UL * timestamp.millis) + (0x100000000UL * 1000UL * timestamp.millis_overflow));

var uptime = new PerformanceCounter("System", "System Up Time");
uptime.NextValue();
var systemUpTimePerformance = TimeSpan.FromSeconds(uptime.NextValue());

The peak timestamp is greater by a couple seconds. An offset of a couple of milliseconds can be expected because the performance counter gives seconds passed for system uptime which could be fine for my use case. Also the peak timestamp should be less because it was stamped before the performance counter one.

Hello,

I think there is a misunderstanding here. I was not aware of the class you are using here, PerformanceCounter. But I think this is not the adequate class for your purpose. This is more a class for counting resources like memory, or network access.

What Uwe meant was using the QueryPerformanceCounter function (C++), which is the actual function used for generating high resolution timestamp on Windows, as I mentioned in my last post.

K.Wagner wrote: ↑
Wed 7. Jun 2023, 12:00
You can use the Stopwatch class, which is based on the Windows API function "QueryPerformanceCounter".

Nevertheless, indifferently if this PerformanceCounter class can be used for accurate timestamping generation or not, you are still using different base values for creating a TimeStamp, what still can end in loosing accuracy, and probably you are still substracting two TimeSpam what also can lead to some truncations as I said in my last post too.

I just wrote a small test app that does what I understood you want to do and I see no problems. It looks like:

: Time difference between performance counter tick count at CAN Init and a received message; Test-Counter.PNG (22.65 KiB) Viewed 11967 times

Each time a mesasge is received, the elapsed time is calculated.

Note that the time shown in Task Manager is the same as the first two values in my test app. The application uses a timer to update the values displayed on the form every second. I have attached the code here in a zip file. It also contains a binary for testing purposes, so you can directly check if this app shows the values as you expect.

Hello,

Is there any new information about this? It would be nice if you let us know whether the code helped you solving your problem.

Hi,

Sorry for the delayed response, I implemented the timestamps similar to the example code that you sent. The QueryPerformanceCounter seems to have solved all my issues. Thank you very much for your help and advice.

I only noticed one small detail while running your example, the "Up time" in the task manager is not "in sync" with the Stopwatch-SystemTime. It is around one minute behind. But luckily this does not affect my application so we can consider this topic solved.

Thank you for your time,

Hello,

thank you for the feedback.

Regarding the value of Up Time, in my opinion, it is possible that microsoft uses for the Task Manager display a normal timer (not performance one), so that always a rounding of up to ~16 milliseconds occurs. Shutting down the PC instead of making a new start actually makes the PC enter a kind of hybernation (Windows Fast-Start), so it is still in operation. The longer the PC runs, the greater the drifting apart can be.

Closed.

PEAK-System Forum

Timestamp value has a delay

Timestamp value has a delay

Re: Timestamp value has a delay

Re: Timestamp value has a delay

Re: Timestamp value has a delay

Re: Timestamp value has a delay

Re: Timestamp value has a delay

Re: Timestamp value has a delay

Re: Timestamp value has a delay

Re: Timestamp value has a delay