Data difference in .csv files

When analyzing SMBus captures, I was confused by the difference in data in the graphs and in the .xlsx table obtained from the .csv file.
Usually, right after I stop capturing, I save it to a .sal file and then export the table to a .csv file.
Faced with a discrepancy between the data in the graph and in the table, I opened one of the saved .sal files and once again exported the table to a .csv file with different name.
I assumed that the .csv file exported immediately after stopping the capture and saving the .sal file and the .csv file exported from the saved .sal file should be identical, but as it turned out, the files differ quite significantly.

Here on the left is the .csv file exported immediately after saving the .sal file, on the right is the .csv file exported after opening the saved corresponding .sal file.
As you can see in the screenshot, the files differ quite significantly, although there are data fragments that completely match (circled in green).
The .xlsx tables obtained from the corresponding .csv files also differ, respectively.

Which .csv file should I trust? Or what am I doing wrong?
If you trust the data from the .csv file exported immediately after saving the .sal file, then why does it not match the graph?

If the correct data is still the data exported from the .csv file after opening the saved corresponding .sal file, then why is this data different from the data exported from the .csv file immediately after saving the .sal file?
TIA

@smarty8
Ouch that’s a 7 Hour (or 420min) time diff for T3 compared to files 43-2.csv and 43.csv. The Logic, capture is out in time according to what I can see for t0, t1, t2…

Id trust the CSV files until proven they are wrong, which shouldnt be the case.

Oh! This is my mistake.
Just when I did Timing Marking T3, I forgot to check the checkbox in Preferences - Wall Clack Time - Use UTC Timezone while both the capture and the table exported to .csv were UTC Timezone format.


Therefore, on the first screenshot, the difference is 7 hours.
Accordingly, when I checked the Use UTC Timezone checkbox, Timing Marking T3 took the appropriate format in which the table was exported to .csv.

Below is the corrected first screenshot for clarity.

But the problem is neither in this, but in the fact that the events and data do not match.

@smarty8 Ok I’m not sure I can help you here, but I’m not sure its a good thing that you have PEC errors, if my memory serves me well this is Packet Error Checks (ing), but am somewhat happy that the BAD PEC is across both files. The error implies that SMBus received the wrong packet or such, so that’s something you should look at tbh

The orange highlighted areas are the ones you believe are inconsistent or ambiguous between the files? Am reading a post between yourself and Tim re PEC, Frame V1 and colors. @timreyes is best suited to respond, as it appears you are using the As Provided SMBus Analyzer and I2C goods. Happy to help if you need it.

I would be glad if you could help me. But I don’t see how you can do it yet.
TIA

@smarty8 Sorry for the late reply! Several of us were out of office last week due to the Labor Day holiday.

In the latest image that you sent, and just taking a look at the blue highlighted items, it looks like some kind of rounding error is occurring somewhere.

Hi, Tim. Glad you responded.
The attached archive contains 3 files from the example from my previous post.
43.sal - data saved immediately after stopping the capture.
43.csv - table data exported immediately after stopping the capture.
43-2.csv - table data exported from file 43.sal when reopened.
But the table data exported immediately after stopping the capture, and the table data exported from the .sal file when reopening, differ not only for this specific capture (43.sal), but always.
TIA.
43.zip (1.2 MB)

@smarty8 Thanks! I’ll get this on the backlog to review with the rest of the team here.

@smarty8 I was able to run some tests with your capture file. Thanks for your patience during this time!

When exporting the data table with the capture file you provided, I was able to match the contents from your 43-2.csv file (which is what I had expected). An immediate look at the 43.csv export file shows a completely different format however.

Your capture file contains a recording of around 45mins of data. My first hunch is that a race condition occurred while you were exporting the data immediately after first stopping your capture. Saving the capture and then subsequently opening that capture and exporting the data table that way seems to be eliminating that race condition factor.

When attempting a shorter capture of SMBus data, and then immediately exporting that data afterwards, I’m not able to reproduce the issue. The data table exported immediately after stopping the capture, and the data table exported after re-opening the saved capture, both have the same contents.

To try and get to the bottom of this, I’ll need your help to run some tests, and hopefully help us reproduce the issue here. You mentioned the following note earlier:

But the table data exported immediately after stopping the capture, and the table data exported from the .sal file when reopening, differ not only for this specific capture (43.sal), but always.

Does the issue occur for short captures of SMBus data as well? For example, when only a few seconds of SMBus data is captured?

As a side note, we typically prevent the race condition I mentioned above by not allowing users to export the data table while data is still being processed by the recently stopped capture, like shown in the image below.

When producing your 43.csv exported file immediately after stopping your capture, were you promted with the pop-up in the image above? I suspect that for a 45min capture, the pop-up above should have been present for some time while data was being processed.

1 Like

No sir!
I’ve never seen a notification like this pop up, either when exporting long or short captures. But a progress bar always appears in the lower left corner of the Logic window indicating the process of saving or exporting. And I never closed the Logic window before the process completed.

@smarty8 Thanks for confirming that. Can you confirm your machine ID with us?

The next step might be to look into any uploaded error reports your PC may have sent to us when the issue occurred on your end while you were exporting.