# Timestamp mismatch in binary export with version 2.4.5 **URL:** \ **Category:** Logic 2 Software\ **Created:** [January 27, 2023, 7:43pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068 "2023-01-27T19:43:20Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![larson](https://avatars.discourse-cdn.com/v4/letter/l/aeb1de/32.png) [@larson](https://discuss.saleae.com/u/larson)\ **Post date:** [January 27, 2023, 7:43pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/1 "2023-01-27T19:43:20Z")
This is very similar to: [Analog export timestamp does not match capture](https://discuss.saleae.com/t/analog-export-timestamp-does-not-match-capture/907) 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: ```auto 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: ```auto 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. ---
**Author:** ![larson](https://avatars.discourse-cdn.com/v4/letter/l/aeb1de/32.png) [@larson](https://discuss.saleae.com/u/larson)\ **Post date:** [January 27, 2023, 8:20pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/2 "2023-01-27T20:20:38Z")
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. ---
**Author:** ![larson](https://avatars.discourse-cdn.com/v4/letter/l/aeb1de/32.png) [@larson](https://discuss.saleae.com/u/larson)\ **Post date:** [January 27, 2023, 8:44pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/3 "2023-01-27T20:44:22Z")
I was just offered 2.4.6 and dowloaded and ran again. The issue is still present there. ---
**Author:** ![timreyes](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/timreyes/32/108_2.png) [@timreyes](https://discuss.saleae.com/u/timreyes)\ **Post date:** [January 28, 2023, 1:35am UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/4 "2023-01-28T01:35:39Z")
@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? > **[The Digital and Analog Recording on the Same Channel Appear Different](https://support.saleae.com/troubleshooting/digital-and-analog-appear-different)** If you think that support article doesn’t explain it, feel free to attach your [capture file](https://support.saleae.com/user-guide/using-logic/saving-loading-and-exporting-data) (in .sal file format) and we can take a closer look at it over here. ---
**Author:** ![larson](https://avatars.discourse-cdn.com/v4/letter/l/aeb1de/32.png) [@larson](https://discuss.saleae.com/u/larson)\ **Post date:** [January 28, 2023, 10:47pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/5 "2023-01-28T22:47:33Z")
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](https://discuss.saleae.com/uploads/short-url/yNxYC3xmrARSwtnMKNPBhgeIrJx.sal) (5.1 MB) ---
**Author:** ![larson](https://avatars.discourse-cdn.com/v4/letter/l/aeb1de/32.png) [@larson](https://discuss.saleae.com/u/larson)\ **Post date:** [January 28, 2023, 10:50pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/6 "2023-01-28T22:50:45Z")
I see this in the CSV export of the analog channel: ```auto 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: ```auto 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: ```auto 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. ---
**Author:** ![timreyes](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/timreyes/32/108_2.png) [@timreyes](https://discuss.saleae.com/u/timreyes)\ **Post date:** [January 30, 2023, 10:52pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/7 "2023-01-30T22:52:20Z")
@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. ---
**Author:** ![larson](https://avatars.discourse-cdn.com/v4/letter/l/aeb1de/32.png) [@larson](https://discuss.saleae.com/u/larson)\ **Post date:** [January 30, 2023, 10:53pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/8 "2023-01-30T22:53:24Z")
No worries Tim, thanks for keeping me in the loop, and happy hunting on this one. ---
**Author:** ![timreyes](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/timreyes/32/108_2.png) [@timreyes](https://discuss.saleae.com/u/timreyes)\ **Post date:** [February 6, 2023, 10:00pm UTC](https://discuss.saleae.com/t/timestamp-mismatch-in-binary-export-with-version-2-4-5/2068/9 "2023-02-06T22:00:02Z")
@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!