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
Initial state: low
Begin time: 3.995592290
End time: 3.999428154
Num transitions: 8160
Time Bit State
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:
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.
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.
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.
@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.