Timestamp mismatch in binary export with version 2.4.5

Logic 2 Software
1

This is very similar to: Analog export timestamp does not match capture

I do a capture of a small number of SPI transactions and then I export them as binary format. Using either my C code to parse the format, or the python examples given to parse the format I can see that the output of the analog does not line up with the digital side. The digital output in the exported .bin files lines up with the capture show in the Saleae tool, but the analog capture is off by a significant amount.

For example, here is the output from digital_0.bin:

python ~/dump_digital.py ~/new_capture/digital_0.bin
Opening /Users/mlarson/new_capture/digital_0.bin
Initial state: low
Begin time: 3.995592290
End time: 3.999428154
Num transitions: 8160
                  Time Bit State
           3.995592290 low
           3.995995488 high
           3.995995560 low
           3.995995616 high
           3.995995680 low

Note that the first HIGH time is 3.995995488.

When I output the analog_0.bin, I see that the first rising transition reported there does not line up with the digital side or the capture as shown in the Saleae UI:

python ~/dump_analog.py ~/new_capture/analog_0.bin
Opening /Users/mlarson/new_capture/analog_0.bin
Begin time:          3.995525300
Sample rate: 50000000
Downsample: 1
Number of samples: 191794
                  Time    Voltage
          3.9955253000     -0.022
          3.9955253200     -0.022
          3.9955253400     -0.022
          3.9955253600     -0.022
          3.9955253800     -0.022
...
          3.9959284400     -0.011
          3.9959284600      0.009
          3.9959284800      0.086
          3.9959285000      0.276
          3.9959285200      0.619
          3.9959285400      1.034
          3.9959285600      1.310
          3.9959285800      1.239
          3.9959286000      0.839
          3.9959286200      0.429
          3.9959286400      0.378
          3.9959286600      0.752
          3.9959286800      1.228
          3.9959287000      1.362
          3.9959287200      1.018
          3.9959287400      0.511
          3.9959287600      0.311
          3.9959287800      0.609

Note that the analog export has a rising/falling transition shown from 3.9959284600-> 3.9959286400, clearly not aligned in time with the digital capture whose first HIGH transition is at 3.995995488. Like the referenced similar issue, the analog times/voltages reported do not line up with the times reported at the top of the Saleae app view of the capture either.

2

I did a CSV output of the same data between the timing markers, and in the CSV case the analog samples are aligned with the App view, and the digital capture. This appears to be an issue with the binary output only.

3

I was just offered 2.4.6 and dowloaded and ran again. The issue is still present there.

4

@larson I suspect the phenomenon we summarize in the support article below might be at play. Can you take a look and let me know if that might be the case?

If you think that support article doesn’t explain it, feel free to attach your capture file (in .sal file format) and we can take a closer look at it over here.

5

Thanks Tim, that article is great and explains a small misalignment, but I still think the problem I am seeing is different as the misalignment is much larger than a few sample windows.

Attached is a simplified capture of a single GPIO which illustrates the issue. Note the CSV export of the capture is much more closely aligned with the digital side (both for CSV and Binary). It is the binary export of the analog that has the offset issue I have been seeing.

SingleGPIO.sal (5.1 MB)

6

I see this in the CSV export of the analog channel:

2.010546162,-0.026
2.010546802,-0.000
2.010547442,0.087
2.010548082,0.298
2.010548722,0.662
2.010549362,1.109
2.010550002,1.509
2.010550642,1.746
2.010551282,1.812
2.010551922,1.787

This matches up nicely with my first digital transition:

Opening /Users/mlarson/single_gpio_toggle/digital_4.bin
Initial state: low
Begin time: 0.000078962
End time: 10.643041522
Num transitions: 4
                  Time Bit State
           0.000078962 low
           2.010549280 high

However the binary output of the analog channel transitions much earlier:

          2.0104659200     -0.031
          2.0104665600     -0.031
          2.0104672000     -0.026
          2.0104678400     -0.000
          2.0104684800      0.087
          2.0104691200      0.298
          2.0104697600      0.662
          2.0104704000      1.109
          2.0104710400      1.509
          2.0104716800      1.746
          2.0104723200      1.812
          2.0104729600      1.787
          2.0104736000      1.756
          2.0104742400      1.746
          2.0104748800      1.756
          2.0104755200      1.761

This is why I think it is not the same as the article you posted.

7

@larson Thanks so much for providing your capture file. At first glance, you might be on to something with the csv export time discrepancy…

I’ll add this on our backlog to thoroughly review and I’ll keep you upated on our findings. Sorry for the trouble with this in the meantime.

8

No worries Tim, thanks for keeping me in the loop, and happy hunting on this one.

9

@larson We ran some more tests on our end, and we’ve confirmed this is in fact a bug. Thanks so much again for letting us know about this discrepancy. The csv looks to be the more “true” result when comparing to the timestamps shown in the software’s waveform display (via timing marker), as per your observations.

We have this on the backlog to fix!