SavvyCAN
SavvyCAN copied to clipboard
collin80
CSV file timestamp incorrect/negative
I have a saved CSV where the timestamps are negative. If it is loaded back in they all show up as zero. If I go into the CSV and remove the negative sign it loads fine. TPMS Log.csv
Hmm, that's strange. SavvyCAN saved the file like that with negative timestamps? Obviously that's not something it should be doing. I see a couple of potential clues.
- They really are in reverse order if you just remove the negative sign. So, they were in proper order before that but have a huge negative offset
- If you do remove the negative signs and load it then interpreting the time stamps as "System Clock" shows that the capture was done on 29-Jan 2023 at around 9:48am which I assume is accurate.
So, this seems like a glitch in applying a time offset for keeping track of the current system time. It seems like it gets applied backward and creates a very large negative offset. Which capture device was used for the file? Maybe it's a bug in one of the capture drivers. And, were you using system clock mode for timekeeping? With the answer to these questions I should be able to find the source of the problem and fix it.
They have a huge negative offset, -1678122502630030 to be presise for a grab done 8-mars-2023
If I just remove the negative sign, the date appears (if i change settings to show date) the files has decreasing timestamp, so the log seems to be done backward in time.
If I subtract this number from all, every Time Stamp gets positive, and are indeed in increasing order in the now modified log-file.
If i subtract the number twice I get the correct time and date as well ( ie correcting for it twice by adding the positive absolutte value twice)
The grab was done by using default setting for time in preferences.
The grab was done using the Peak-CAN unit, I've not tested using the CANDue, but I have one around here somewhere if testing makes it necessary. I believe I have the parts to build an ESP32 based unit as well...
An option to just make the first Time Stamp timestamp zero, whatever it is, would work perfectly for me and would solve this issue i presume? :)
I was using a PCAN.
The value in Byte 1 of my file should count up from 1 to 4 and repeat, which it does in the csv file so i know it's in the right order. If I simply remove the negative sign and resort, it counts down from 4 to 1, so it is indeed a big offset rather than simply just having a negative attached to the correct time stamp.
The file was recorded on Jan 29th. The created date of the CSV is 3:12PM, I don't recall what time it actually was but the date is right.
One other note-- its not consistent. I've only seen it once and other captures from the same setup were fine.
We do have it in all captures for the last 4 months at least. On two different vanilla installs on two different Win10 laptops.
Had the same issue with 32 bit program and openport passthru connection on last main branch
