Data difference in .csv files

[smarty8]

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

[b.hughes1]

@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.

[smarty8]

@b.hughes1

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.

[b.hughes1]

@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.

[smarty8]

@b.hughes1

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

[timreyes]

@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.

• Can you help send over your capture file (in .sal file format)?
• If needed, you can trim your capture file to reduce the file size.

[smarty8]

@timreyes

Can you help send over your capture file (in .sal file format)?

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)

[timreyes]

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

[timreyes]

@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.

[smarty8]

@timreyes

When producing your 43.csv exported file immediately after stopping your capture, were you promted with the pop-up in the image above?

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.

[timreyes]

@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.

[wgoebel]

Not sure if this topic is still active, but I am having a similar issue: when recording SMBus data for a longer period (more than a minute or so) and having the SMBus analyzer active during capture (Stream to terminal / Show in data table options checked), an immediate export of the data table produces incorrect data; changing the SMBus decode level to signals, then back to bytes (and then waiting for the processing of the data to be finished, waiting for the “100%” to be shown) before doing the export solves the problem for me. I have never seen the “Export will be available…” dialog. Saleae Analyzer version I am using is 2.4.7 (due to IT restrictions update procedure is not easily possible).

[timreyes]

@wgoebel Thanks for letting us know about the issue on your end. We never got to the bottom of it so this issue is still open. I’d like to gather some more information from you in the meantime.

• Does the issue only occur when exporting the data table immediately after the capture is stopped?
• Is there any way you can reproduce the issue with a previously-saved .sal capture file? If so, can you share the capture file? That will help us reproduce the issue on our end.
• Can you share your machine ID with us?
• Can you share a copy of the exported data table that contains the incorrect data?
• Can you share a copy of the exported data table that contains the correct data?
• If possible, can you provide a screen recording that shows the issue in action?

[BitBob]

FYI, a possible clue –

If you crop the previously provided 43.sal capture file to cut the first ‘write’ command, then the initial CSV output seems to match the ‘unexpected’ format seen previously. However, this only works for the first sequence, and thereafter diverges.

Attach:
43-cropped.zip (1.1 MB)

So, maybe the SMBus analyzer is somehow losing the ‘write’ sequences when on an extended ‘live’ session, but while in an offline re-analysis of the same sequence it decodes properly (??)

In this case, it would help to observe what is in the initial ‘live’ captures analyzer data view – does it show the same ‘Protocol=Quick Command’ values there as well? (e.g., is it failing to decode, or just failing to export?)

When I did the ‘cropped’ capture, these two views both matched:

Data View:

vs. CSV exported output/view:

name,type,start_time,duration,"value"
"SMBus","v1frame",2023-08-04T02:47:56.792966400+00:00,8e-06,""
"SMBus","v1frame",2023-08-04T02:47:56.792981400+00:00,0.000108,"Read address 0x3D ACK Protocol=Quick Command"
"SMBus","v1frame",2023-08-04T02:47:56.793089400+00:00,0.000109,"Bad PEC 0x3F should be 0x66"
"SMBus","v1frame",2023-08-04T02:47:56.793205400+00:00,8e-06,""

Originally (i.e., from the 43.sal opened before cropping):

[timreyes]

@BitBob Oh interesting, thanks so much for sharing those findings. You might be on to something with your statement below.

@BitBob

So, maybe the SMBus analyzer is somehow losing the ‘write’ sequences when on an extended ‘live’ session, but while in an offline re-analysis of the same sequence it decodes properly (??)

I’ll share that with the team here and we’ll take another look.

[markgarrison]

Thanks everyone for the details.

This looks like a bug in the SMBus analyzer.

I was able to modify the simulated data generator temporarily to reproduce what seems like the same issue, and then implement a fix: Fix invalid results when running in real-time. by Marcus10110 · Pull Request #3 · saleae/smbus-analyzer · GitHub

However, I don’t have a really good way to test this here. Ideally, if @smarty8 or @wgoebel happens to still be working on SMBus recordings, it would be great if you could test the fix.

To test, you just need a github account to download the analyzer. Once you are signed into github.com, go to this page: Fix invalid results when running in real-time. · saleae/smbus-analyzer@72b0c8e · GitHub

Scroll to the bottom, you will find a section called “Artifacts”. You can click the name of your platform to download the correct file, e.g. “windows”. Note if you are not signed into github.com, the artifacts won’t be downloadable.

Once you extract the zip file you have downloaded, you will want to back-up the smbus analyzer you already have, and then copy & paste the new SMBus analyzer into your analyzers directory. Note - you cannot have both the old and new SMBus analyzer loaded at the same time. This is because our software can’t handle multiple analyzers loaded that have exactly the same name.

Analyzers can be found here on Windows:
C:\Program Files\Logic\resources\windows-x64\Analyzers

Make sure that Logic 2 is not running.

move the old smbus_analyzer.dll out of that directory, then copy in the new one. Note, simply re-naming the old smbus_analyzer.dll might not work, because the analyzer name is imbedded in the DLL. If you change the file extension to something other than *.dll, that will prevent it from getting loaded.

Copy the new smbus_analyzer.dll into the same directory, then launch the software.

Notes on testing:

1. The bug only occurs while the SMbus analyzer is running in real-time. If you add the SMBus analyzer after the recording is complete, or edit any of the settings of the SMBus analyzer after recording, this will cause the SMBus analyzer to run on the already recorded capture, which was already working properly.
2. The best thing to do is to export the CSV right after recording, before doing anything else.
3. You can easily restart the analyzer by right-clicking it and selecting “restart”. This should be faster than saving and re-loading the *.sal file, and have the same effect.

We’re looking for 2 things:

1. The SMBus results are decoded correctly
2. The SMBus analyzer produces the same results for both the real time case and the already-recorded case.

Background:

Our analyzers run in what we consider 2 different “modes”. First, the real time mode. This is when the analyzer is running at the same time the data is being recorded from the device. In this mode, the analyzer processes one bock of data at a time. Analyzers may spend a lot of time blocked while waiting for more data.

The second mode is when the analyzer is run on a complete recording. This happens when you add an analyzer to an existing capture, edit the settings on an analyzer on a completed recording, or load a file that contains analyzers. In this mode, 100% of the data in the recording is available when the analyzer starts.

Our analyzers are designed to work properly in both cases. However, after taking a quick glance at the SMBus analyzer source, I was able to find a bug that could cause it to produce invalid results in the ream time case. There is more detail of the problem in the Github PR link posted above, but basically the analyzer wasn’t written with the real-time case in mind, and was likely mainly tested on SMBus analyzer saves.

[wgoebel]

Hi Mark,

Followed your steps, the new analyzer seems to work as expected. What I did was (twice with old analyzer and new analyzer)

• Selected SMBus analyzer in byte mode
• Record digital signals (8 channels, first 2 are used for SMBus system 1) till memory consumption was ~25Mb
• Export data as csv (filename: export_afterStopCapture…)
• Change analyzer mode from bytes to signals and back (as you have written the “restart” should give same results)
• Exported data again as csv (filename: export_afterChangeBytesToSignalsToByte…)
• Old analyzer: There is already a difference in file size shown by windows explorer; file compare shows a lot of differences
  (see screenshot 1)
• New analyzer: no difference in file size, file compare shows files are identical
  (see screenshot 2)

Screenshots and csv export files are attached as zip for your info (please do not distribute further)

Best regards

Werner

Screenshot 1:

Screenshot 2:

(Attachment Salea.7z is missing)

[markgarrison]

Thanks Werner! We’ll plan to get that into the next release.