Timestamps break when importing a SavvyCAN gvret .csv from someone else

[larsrengersen]

We both use V213 The log I receive from the other user has negative timestamps. E.g. -1717751916236254 When I save a log I have normal positive timestamps.

And when I try to import his .csv then all my timestamps are 0 so I cannot use the graph functionality.

Any known workarounds / solutions for this?

[collin80]

It's a known issue that I need to fix. The problem is that we're so far past the time epoch (Jan 1, 1970 I think) that the time requires enough bits to represent that accidentally using a signed integer causes it to be negative instead of very, very positive.

The work around is to not use System Clock as the timestamping format when saving. If the log used seconds then it'll get saved as microseconds in the log but starting at 0 microseconds upon start up so you can't have SavvyCAN running long enough for it to get to the positive/negative switch over.

But, I'll bet I can fix it by forcing the use of unsigned integers for the timestamp which should then magically make it "do the right thing" and be a very large positive number again.

What I have done before is to take all the minus signs out of the file. Nothing else should have - so if you find and replace - and replace it with nothing you get a file that loads but all the timestamps are backward. This is not ideal but it at least lets you graph it. Just remember that the graph is backward in time.

I'll look at this today and see if I can fix it quickly.

[collin80]

FWIW, I tried to test this on the current version of SavvyCAN and it no longer has the improper behavior when saving. Now it can save timestamps with quadrillions of microseconds properly. I just tried using system clock with my current system time and date and the number is 1.7 quadrillion but it saves properly and positive. I do know that past versions had the problem though. Currently the save/load system can handle signed 64 bit numbers which is enough for about 260 thousand years of timestamp. Hopefully someone has made something better by then.

So, the best advice is probably either

1. Do what I said above and remove all the negative signs (yielding a backward list of timestamps)
2. Upgrade to the continuous integration build of SavvyCAN

[larsrengersen]

Thanks for your quick response and sorry for the delay in my feedback. I found the replace -1 to 1 workaround and it works OK but not very convenient when sharing with others. I tested te latest build but the problem persisted. This was with a file I received. Will test myself on two computers. When I save logs myself it works out OK (even with V213). Will test and update here later.

[aeitzer]

Is there any fix for this issue? I am having the same problem.

[collin80]

I fixed it in the QT6 branch but I should probably port it to the QT5 version as well. The fix somewhat breaks the actual time stamp, it could be years off but at least the frames will all come through with the proper offset from each other. I will see if I can fix it better so that the timestamp comes through absolutely correctly.

[aeitzer]

Thanks colin, we'll try to checkout the QT6 branch and run some tests. Appreciate the quick response

[collin80]

I'm getting reports that the QT6 continuous build is also still broken so it seems like I didn't actually fix it there either. Need to look into this more.

[franco6996]

I have the same problem saving a log file in the v221. It saves it as a negative number.